Microsoft to the core
by Tim Anderson
The latest version of ASP.NET sees major changes to Microsoft’s web development platform.
HardCopy Issue: 69 | Published: June 1, 2016
Microsoft is making major changes to its web application framework, ASP.NET. The new release, called ASP.NET Core, is a landmark of the kind that the company comes up with every six or seven years:
2002 – ASP.NET released as part of the .NET Framework
2009 – ASP.NET MVC released as an alternative to Web Forms
2016 – ASP.NET Core scheduled for release
However this table is somewhat misleading, in that ASP.NET MVC did not replace Web Forms but was initially a low key release designed to meet the need for a leaner and more flexible framework. The Web Forms approach is a remarkably successful attempt to make server-side web development work with visual design tools and a stateful model. It is also easy for third-parties to support with components, making it highly productive.
Microsoft has gradually shifted most of its development effort to ASP.NET MVC, but Web Forms are not deprecated. The latest version is ASP.NET 4.6, with new features including HTTP/2 support giving fast binary transmission with concurrent delivery of resources; asynchronous model binding; and support for the .NET Compiler platform previously known as Roslyn. There is also support for authenticating to Azure Active Directory (the same directory used by Office 365) using Open ID, and this is now part of the ASP.NET 4.6 templates in Visual Studio.
This means that developers can continue to use ASP.NET 4.x and Web Forms for the foreseeable future.
At the same time, Microsoft is moving ahead with profound changes to both ASP.NET and .NET itself. The company has forked the .NET Framework into a new open source, cross-platform runtime and libraries called .NET Core. This was done for three primary reasons.
First there is the move towards modularity. Microsoft wanted to make the .NET Framework modular so that only those parts actually needed by an application have to be deployed. According to Microsoft, it was not possible to refactor the full .NET Framework because of complex internal dependencies. By contrast, .NET Core is designed as a set of NuGet packages (NuGet being the open source package manager that comes with Visual Studio). Applications can declare which version of each package they require and each package can be updated separately, allowing an agile approach. A further implication is that .NET Core is deployed locally for each application, rather than system-wide, so that updating .NET Core does not break other applications.
Secondly, Microsoft is becoming a cross-platform company. Microsoft Office runs on iOS and Android; SQL Server is coming to Linux; and Azure hosts Linux virtual machines. The company’s investment in cloud services, including Office 365 as well as Azure, means that it can profit from applications calling those cloud services from any platform. Microsoft therefore decided to take .NET cross-platform as well, and rather than attempting to unhook the existing .NET Framework from its Windows dependencies, it chose to start again with code designed for cross-platform development from the beginning.
Thirdly, Microsoft has embraced open source. “We are open sourcing the .NET Core Runtime. This will include everything needed to execute .NET code, including the CLR, Just-In-Time Compiler (JIT), Garbage Collector (GC) and core .NET base class libraries,” said Microsoft Corporate vice-president Scott Guthrie in November 2014. Guthrie cited closer cooperation between Microsoft teams and other developers as a key benefit, “enabling an even richer flow of ideas, and even better products.”
Furthermore, open source in this context does not just mean publishing the source, but also accepting community contributions. The code for .NET Core is on Github and overseen by the .NET Foundation, set up by Microsoft as an “independent forum to foster the open development and collaboration on the growing collection of open source technologies for .NET,” according to the FAQ on its website.
Although .NET Core runs only a subset of the full .NET Framework, excluding for example the GUI frameworks Windows Forms and Windows Presentation Foundation, it does run a version of ASP.NET. First known as ASP.NET vNext, and then as ASP.NET 5, the official name of this release is now ASP.NET Core. As with .NET Core, ASP.NET Core is a subset of ASP.NET 4.6, and does not include Web Forms. In its first release it will also not support Visual Basic, the Web Pages framework, or the SignalR real-time communications framework, although support for these is planned for future versions.
It is worth noting that ADO.NET data access is not fully supported in .NET Core. Instead the primary data access mechanism is Microsoft’s object-relational mapping library Entity Framework 7, which has providers for SQL Server, SQLite, PostgresSQL, IBM data servers and in-memory data (for testing). Other providers will be developed but data access will initially be one of the trickier areas for porting existing projects.
Inside ASP.NET Core
ASP.NET Core follows the same pattern as .NET Core, being modular, cross-platform on Windows, Mac and Linux, and open source. Mac support is primarily intended for development since Macs are popular among developers, and required for iOS compilation.
At the same time, for those working on Windows, ASP.NET Core also runs on the full .NET Framework 4.6, with the advantage of a mature runtime environment that is serviced as part of Windows Server. That said, some of the advantages of ASP.NET Core only apply when taken together with .NET Core.
A key feature of ASP.NET Core is its modular HTTP request pipeline. It uses the concept of ‘middleware’ to refer to components that handle requests and responses. Each middleware component passes on requests to the next. Examples of middleware components are StaticFiles for serving static web pages, ExceptionHandler for redirecting to a special page after an exception, and MVC for routing requests according to the ASP.NET MVC view/controller model.
Each application has a Configure method which sets up the request pipeline. This means that there is no overhead from unused middleware components, and you can also vary the pipeline between development and production.
Modularity in ASP.NET Core is not just for the request pipeline. The framework ships as a set of NuGet packages, so developers can use exactly the packages and versions they require. Side by side deployment means each application is self-contained.
The Web API framework in ASP.NET is increasingly important for applications which form the server back-end for mobile apps. In ASP.NET 4.x, the Web API is a separate framework from ASP.NET MVC. In ASP.NET Core, the Web API and MVC share the same code, making the frameworks easier to maintain and develop.
ASP.NET Core also supports self-hosting, when deployed using .NET Core.
Dependency Injection is built into ASP.NET Core. Dependency Injection is a programming pattern where references to other objects are passed into an object, either in its constructor or by setting properties, rather than the object having to know where to get those references. ASP.NET Core uses Dependency Injection to configure services, such as the middleware mentioned above, when the application starts.
The Razor view engine has been revised in ASP.NET Core with a new feature called Taghelpers. Taghelpers are server-side attributes that can be used in many of the scenarios where today you would embed C# code into a Razor cshtml file. There are built-in Taghelpers for things like forms, input validation and labels, or you can easily write custom Taghelpers. In effect they are new HTML tags that get replaced server-side, which means they are never seen by the client browser itself. They make Razor code cleaner as well as supporting IntelliSense.
Another new Razor feature is the ability to render HTML asynchronously. This means you can send parts of the HTML to the client immediately, following up with content that requires more processing time when it becomes available, so giving the user a better experience.
Microservices and Containers
It goes without saying that reliability, scalability and the ability to deliver changes and improvements quickly are all desirable characteristics of software development. Views on how to achieve these things have changed over the years and as new technology has become available. The advent of virtualisation was revolutionary since it enabled a flexible infrastructure where virtual servers can be created and removed in minutes, rather than the old model of buying, installing and configuring hardware servers. Cloud computing takes this a step further, with resources available on demand. The boundaries between hardware and software have blurred, with the ability to define server configuration in software and automatically instantiate the servers you need to run your application. DevOps tools let you automate software deployment, and when combined with comprehensive tests give the ability to make changes to code and have it deployed safely and automatically, a process called Continuous Delivery.
In this new world there is an advantage in composing complex applications out of a number of sharply-focused components, each of which operates independently. This is an architectural style based on ‘microservices’, with scalability and resilience coming from the ability to run multiple instances of each microservice.
If you take this kind of approach, it is obvious that small, lightweight servers for hosting microservices are better than large multi-purpose servers, since you can then run more servers on the same physical infrastructure, create them more quickly, and reduce the burden of patching and maintenance. This requirement gave rise to the idea of a container, something which looks like a virtual server in that it is an isolated environment which can run an application, but which shares operating system resources with other containers.
Microsoft has been working to transform Windows Server into an operating system that is optimised for this type of deployment. Two features in the forthcoming Windows Server 2016 are notable. One is Windows Server Containers, which make containers an integral part of the operating system. The other is Nano Server, a stripped-down edition of Windows Server that can only be administered remotely, since it does not support local log-on. Nano Server is designed as a lightweight and secure host for Hyper-V virtual machines, or as a low-overhead operating system for containers or virtual machines. Nano Server boots more quickly than a full version of Windows, making it more efficient in automated deployment.
Linux is in some respects ahead of Windows Server here since it is already suitable for small lightweight distributions, and containers were first developed in a Linux environment. Microsoft’s Azure cloud platform already supports Linux containers in its recently released Container Service.
It is this context which makes ASP.NET Core a necessary technology for Microsoft. The modular design of .NET Core and ASP.NET Core is well suited to microservices and containers, and the ability to run on Linux as well as Windows means that it will work in any modern environment.
Nano Server does not support the full .NET Framework, but only .NET Core, so the transition will be necessary if you are to take advantage of Nano Server deployment.
The path to ASP.NET Core
The evolution of ASP.NET Core has not been entirely smooth. In November 2015 Microsoft released ASP.NET 5 RC1, complete with a go-live licence allowing production use. “.NET Core and ASP.NET 5 are now largely feature complete on Linux, OS X and Windows,” said Program Manager Rich Lander in a blog post.
ASP.NET 5 RC1 uses a runtime environment called DNX (.NET Execution Environment). The DNX Version Manager (DNVM) lets you install and manage different versions of DNX on your machine. DNX provides a host process for ASP.NET 5, enabling standalone deployment. DNX also provides tools for package management. The DNU (.NET Utilities) reads and downloads the packages defined in a project.json configuration file, when run with the restore command.
It turned out though that the team was not as far along as it thought. In February 2016 Program Manager Jeffrey Fritz wrote that “it was decided to rename ASP.NET 5 to ASP.NET Core 1.0,” and more significantly, confirmed that DNX was to be dropped in favour of an alternative called the .NET CLI (Command Line Interface). “We’ve heard consistent feedback on the change from DNX to CLI: ‘great change, but why so late?’” wrote Fritz, admitting that this would push back the schedule, though ASP.NET Core is still scheduled to reach version 1.0 in 2016. The next version, RC2, will use CLI instead of DNX.
The .NET CLI is even easier to use than DNX. You can create, compile and run a ‘Hello world’ application with the following commands (see screenshot):
This creates a skeleton application.
This restores NuGet packages according to the configuration in project.json.
This builds and runs the application.
Another useful command is dotnet build which performs a build without running the application.
You cannot yet create a skeleton ASP.NET Core application with the .NET CLI, but this will likely be possible.
Native code compilation is also planned. A command like dotnet compile –native will generate a native executable that does not require the .NET Core runtime.
But at the time of writing, it is unfortunate that ASP.NET 5 RC1 is the latest stable release with reasonable documentation, while it is well known that RC2 will have major differences.
Microsoft’s work with ASP.NET Core is exciting, but it is early days. Despite the go-live licence for ASP.NET 5 RC1, in most cases developers will only want to use it for experimentation, and forming a judgement about how difficult it will be to port existing applications to the new framework, and whether its slimmed-down library is sufficient for new projects. The familiar and trusted environment of .NET Framework 4.6 remains in place for production work.
That said, it is clear that ASP.NET Core is in some sense ‘the future’ for Microsoft’s web platform, and in combination with changes in Windows Server and services available on Azure, other public clouds, or internal cloud-like infrastructure, it promises substantial benefits in terms of performance, agility, and cross-platform flexibility.