Part of the ASP.NET vNext initiative, ASP.NET MVC 6 represents a fundamental change to how Microsoft constructs and deploys web frameworks. The goal is to create a host agnostic framework that eliminates the dependencies on the legacy System.Web infrastructure.

Microsoft feels that System.Web needs to be removed because it is actually quite expensive. A typical HttpContext object graph can consume 30K of memory per request. When working with small JSON-style requests this represents a disproportionately high cost. With MVC 6 new design, the pre-request overhead drops to roughly 2K.

Included in MVC 6 is Web API and Web Pages, allowing Microsoft to remove a lot of the overlap between the three frameworks. One result of this change means that MVC will be self-hosting just like Web API 2 and SignalR 2.

In order to make deployment easier and more reliable, “vNext will support true side-by-side deployment.” Rather than being installed in the GAC, each MVC library needed for a given web site will be referenced like a normal developer-created DLL. “That means you can update your app without affecting other applications on the same server.”

Pay As You Go

MVC 6 is built on a “pay as you go” philosophy. Each feature that you wish to use has to be explicitly turned on in the application startup routine. Even serving up static files requires calling IBuilder.UseStaticFiles.

The way this works is that each website needs to have a class named Startup and this class must have a method called “void Configure (IBuilder app)”. Inside this method you can call functions such as “app.UseServices” to enable features such as MVC.

Routing is also setup in the Configuration method. MVC 6 routes are similar, but not identical, to MVC 5 routes. For example, a question mark can be added to a fragment to make it optional in MVC 6. In MVC 5 you would use the UrlParameter.Optional value for the same effect.

Azure and PowerShell Based Deployments

Microsoft is still heavily pushing Azure as the standard way to deploy websites. But they have realized that developers are leery of publishing websites directly from Visual Studio. So instead they will generate PowerShell deployment scripts by default. These can then be edited inside Visual Studio, which now has basic tooling support for PowerShell.

The Build Process Doesn’t Build

In ASP.NET vNext the build process does not actually build anything. No binaries are generated, it merely runs the type checker to ensure you don’t have any errors or warnings that need to be addressed. Instead the code is compiled on the fly in an as-needed basis, much like we already see with ASP.NET Web Pages. This allows for faster iterations, especially over large websites.

If you want actual binaries to be deployed on a server you need to run the package and publish command. Eventually this will offer several options from source code only, which will continue to compile on the fly, all the way up to natively compiled. The latter should have better performance, but could entail a much longer build process.

Many APIs Will Be Moved or Removed

As mentioned before, they are reducing the size of HttpContext from roughly 30K per request to 2K per request. This isn’t free, the cost of that is a significantly reduced set of methods on that object and its children. And by the time they are done it is probably not going to be the only API trimmed down in size.

In order to make this transition less painful, they intend to develop an FxCop like tool that will detect when legacy APIs calls are being made. While it won’t be able to automatically rewrite your code, it can at least tell you what needs to be changed before migrating to ASP.NET vNext and MVC 6.

Sometimes the change will just involve calling a different method from an optional package or library. Other times the code will need to be significantly rewritten. Since the product is still in alpha a complete list of these changes is not yet available.

Full Framework vs Cloud Optimized Framework

The above warnings come into play because they are removing their dependency on System.Web but otherwise stay on the full .NET Framework. If you take the next step and go with what they are calling the “Cloud Optimized Framework” then you lose access to even more APIs. In the Channel 9 Q&A session they mentioned System.Drawing as an example of what you can’t use.

The advantage of using the Cloud Optimized Framework is that you can include a copy of the Core (or Mono) CLR with your website. You no longer have to upgrade .NET on the entire machine for the sake of one website. You can even have different versions of the CLR for different websites running side by side.

The Core CLR is also supposed to be tuned with a “high resource-efficient optimization”. Exactly what that means has not yet been revealed.

Libraries vs Packages

Under the .NET vNext model, projects don’t reference individual libraries anymore. Instead they reference NuGet Packages. As you probably know, packages can contain multiple versions of a library divided by target platform. ASP.NET vNext can leverage this to decide at runtime whether to load the Full .NET, Mono, or Core CLR version of a given library.

If this doesn’t sound palatable to you, there will also the option to use Portable Class Libraries. Though it isn’t ready yet, they plan on creating a PCL profile for the Cloud Optimized Framework.

Mono is a Supported Platform

In the past the support story for Mono was essentially “we hope it runs, but if it doesn’t then you need to talk to Xamarin”. Now Microsoft is billing Mono as the official cross-platform CLR for ASP.NET vNext. To that effect they are actively working with the Mono teams to ensure it has everything they need and will include Mono in their Continuous Integration testing.

That said, Microsoft isn’t offering official support for Mono via their paid support channels. They are only promising to maintain compatibility and that if a CI test fails they will work with the Mono teams to fix it.

Cross Platform Development

Not only is Microsoft planning for cross-platform deployment, they are also enabling cross-platform development. Batch files for the major platforms such as OS X and Linux will be provided so that you can package and deploy ASP.NET vNext projects without needing Windows and Visual Studio.

Part of this is the KPM or the “Katana Packaged Modules”, which were inspired by Node Packaged Modules. Katana was a research project for modularizing ASP.NET MVC for use on Owin. KPM will use the NuGet repository on the backend.

Trying it Out

The preview version of the ASP.NET vNext binaries are available now. Visual Studio support is expected to be available in three to four weeks.