I’ve had the chance to sit down and work with Visual Studio 2015 Release Candidate. While not the finished product, I suspect a lot of this is close to what we will be seeing in the final bits of Visual Studio 2015.
DNX Is Not RC
A first thing to point out, is while this is the Release Candidate for Visual Studio 2015, it is not a release candidate for ASP.NET 5, or the DNX Framework or Tools. These are still very much at “beta” quality. MVC6 and many other packages are on Beta 4.
These are going to take a bit longer to update, and as Microsoft has stated, they are going to continue to do work on these NuGet packages even once Visual Studio 2015 ships. Gone are the days of huge monolithic release – .NET and Visual Studio and Libraries all once. As more and more components are shifted to NuGet packages, the easier it will be for those components to be updated.
The upshot to all of this is we get more new things more frequently. MVC was really the trendsetter for this, and it has worked out quite well1. The downside is, we may not be getting a perfectly seamless product when Visual Studio 2015 ships. That’s all still up in the air, and it shows with the current release.
DNX… Core… What’s going on here?
There’s been some considerable changes in ASP.NET 5. It’s a far flung departure from what we have today, and there are a lot of new concepts to wrap your head around. If you are keen on upgrading, you have a choice on your upgrade path for ASP.NET project or if starting a new one.
Along with ASP.NET 5, there is an ASP.NET 4.6. ASP.NET 4.6 is very similar to the ASP.NET you know and love today. It has Web Forms (.aspx), MVC, Web API, and any combination of the three. It still uses traditional Project files. This is a fairly frictionless upgrade path, but at the cost of not having the latest-and-greatest. MVC 6 will not work in this kind of project. MVC 5 is still there, and may receive updates still. MVC 6 is a pretty big departure from MVC 5 and prior.
ASP.NET 5 is where all of the big changes come in. Web Forms are a thing of the past – there are no Web Forms for ASP.NET 5. There isn’t Visual Basic .NET support, either. However Microsoft has promised2 they will add VB.NET support after ASP.NET 5 ships. If you make use of Web Forms or VB.NET, that limits things to ASP.NET 4.6 for now.
ASP.NET 5 brings some big changes. The big outstanding ones is a new “Core” runtime that allows cross-platform deployment, called DNX Core 5. DNX is short for .NET Execution Environment, and consists of several other tools. If you build your web application on the Core runtime, you should be able to run it on Windows, Mac, and certain *Nix platforms with little to no special coding. The downside to this Core runtime is it is a subset of the full .NET Framework – many library classes are not available. As the DNX Core framework matures, more things will be added and ported to the Core framework. To make this work, many parts of the .NET Framework that are available today have been broken up into NuGet packages. As more things are brought to the DNX Core framework, NuGet packages will get updated and new ones will become available.
If cross-platform isn’t on your radar, you can still do full .NET Framework development with ASP.NET on DNX 4.5.1. This name probably isn’t going to remain, it is likely to get changed to DNX 4.63.
Let’s try and summarize this.
- ASP.NET 4.6 is very familiar to what we have today, Web Forms, MVC 5, etc. It uses the .NET Framework 4.6.
- For ASP.NET 5, there are two Frameworks: DNX Core 5 and DNX 4.5.1 (likely to be changed to DNX 4.6). The former is a subset of the full .NET Framework that supports cross platform. DNX 4.5.1 uses the full .NET Framework 4.6.
- DNX is a “.NET Execution Environment” that consists of a runtime, framework, and tooling.
The next question might be, if the DNX 4.5.1 / 4.6 uses the .NET Framework 4.6, how is that different from ASP.NET 4.6 using the .NET Framework 4.6?
One of the main goals of ASP.NET is to completely decouple all components from the System.Web assembly. This assembly has served us well over the years, but it has a major flaw: it assumes the web server will always be Internet Information Services (IIS). This makes cross-platform impossible or a terrible hack, it also prohibits “self hosting”. If you’ve ever wanted to run a small web server in a Windows Service or Console Application, you couldn’t due to that IIS dependency. There has been a lot of attempts to get this working well over the years, but all of it was friction with System.Web.dll.
If this sounds familiar, it’s because a lot of this work has been going on for a long time already with OWIN. OWIN in a nutshell is an interface or specification that acts between various web frameworks and the underlying web server. This has already been achieved with SignalR 2 and WebAPI – both can be self hosted today, but only on Windows. However all of the legwork was done there – all that was missing was a runtime and CLR that implemented the OWIN specification on other platforms, and that is what we are getting with ASP.NET 5.
DNX, DNVM, and nuget
If you have been doing any work with Visual Studio 2015 CTPs or previous beta of MVC6, or have been reading about ASP.NET 5, you will see all of the tools, “k”, “re”, and “cpm” aren’t there anymore. Where did they go? These were the previous names of the DNX tools, and have since been renamed4.
There are a few tools to familiarize yourself with.
dnx is a command line tool that acts as an entry point to an application. If you are coming from a node.js background, or are familiar with it, you can liken it to the
node command line tool. It actually bootstraps the execution of an application. Previously, this was called the KLR.
dnvm.ps1 (and .sh) is the version manager. This tool manages which DNXs are installed, and which is the primary one. For the node folks, this is similar to the
nvm, or for Ruby
nuget is the package manager. It can restore package dependencies, and create new packages. This serve’s as node.js’s
You can see there is a lot of inspiration from how many other development stacks do it: you have your entry point, version manager, and package manager. This isn’t a mistake: the goal here is to use familiar experiences and terminology that exists today on other platforms and bring those terms to .NET, not introduce new ones.
As touched on previously, ASP.NET 5 has really made OWIN a front-and-center requirement. Everything must now use the OWIN specification to run in ASP.NET 5, including MVC 6.
OWIN itself is not a server, it is purely interfaces that act as a specification. The implementors of those interfaces allow those web components to talk to the web server in an agnostic way. One such implementation is Katana. Katana has been around for a while. If you were using OWIN before ASP.NET 5 with IIS, chances are the OWIN implementation you were using was Katana. If you were self hosting SignalR, you were using HTTPListener.
In ASP.NET 5, the new implementation of OWIN is Helios for IIS. The name Helios isn’t seen much anywhere, rather it has been renamed to Microsoft.AspNet.Server.IIS. Helios has several advantages over Katana. Katana was still heavily dependent on System.Web to accomplish anything. Helios on the other hand, has no dependency on System.Web. This gives quite a bit more flexibility with self hosting.
Since MVC is transitioning away from System.Web to OWIN, there are going to be breaking changes.
MVC 6 and getting started with Visual Studio 2015 RC
I’ll give three warnings on Visual Studio 2015 RC. The first is, this is a release candidate. Visual Studio may be unstable, I myself have already filed a couple of bugs on it. Secondly, as I pointed out in the beginning, the nugget packages themselves are still very much more of a beta quality. Things may break as they get closer to RTW. Thirdly, when I installed the Release Candidate, I had the option to import all of my settings and preferences from Visual Studio 2013. This did not go well – intenseness was complete broken for me. Undoing this got everything working again.
MVC 6 is similar in a lot of ways. Many of the conventions are still there, controllers are classes that have action methods on them, Views are .cshtml files with Razor in them. However many other things work differently, such as routing. ASP.NET 5 has no Global.asax or corresponding code behind for it. Instead with OWIN, we use the Startup.cs file. I’m going to start with an “Empty” ASP.NET vNext project in Visual Studio 2015 RC and add MVC 6 to it in a basic manner so we can see how to wire it up.
The empty project template includes a simple
WriteLine that says Hello World! – go ahead and nuke that so that the
Configure method is completely empty in Startup.cs. First, we need to add a dependency on MVC 6, this is done in the project.son file. There is a property called “dependencies”, which we can add NuGet packages to. We’ll add MVC 6 beta45 as a dependency. My dependencies property now looks like this:
When you modify this file, Visual Studio will automatically pull down the package for you if it needs to. If for whatever reason Visual Studio doesn’t do that, you can use Ctrl+Shift+K,Ctrl+Shift+R to manually perform a package restore. Now that we have MVC added, jump back to the Startup.cs file. Adding the nuget dependency to MVC puts some extension methods in place for ConfigureServices and Configure.
public void ConfigureServices(IServiceCollection services)
public void Configure(IApplicationBuilder app)
ConfigureServices is used to services, or dependencies to your application. The Configure is used to configure your OWIN pipeline, or really to describe how a request should be handled. In Configure, we are adding MVC to be able to handle requests through our pipeline if MVC agrees that it can handle it.
UseMvc method has an overload that lets us build our routes:
Since there is no web forms here, the usual IgnoreRoute for *.axd is gone – AXDs are part of the legacy ASP.NET pipeline which we are leaving behind.
To configure MVC, that is done with the
ConfigureMvc extension method off of
ConfigureServices. This is where a lot of the things you would normally do in Application_Start for previous versions of MVC, such as adding global filters, custom model binders, etc. This is optional for getting a basic MVC application up and running, but it’s common enough to use these features.
Next I added a folder called “Controllers” to my project, and added a controller called “DefaultController”.
public class DefaultController : Controller
public IActionResult Index()
This is all very familiar to the way previous versions of MVC worked. The exception to this is that ActionResult is now an IActionResult. You can still choose to declare your action methods as ActionResult instead of IActionResult.
Finally, I added a Views folder and a Default folder for my Index view.
After adding some simple Hello World HTML to my view, I can pull it up in my browser.
As far as Controllers and Views go, these are largely the same from MVC 5. If you use the built-in attribute routing, you don’t call
routes.MapMvcAttributeRoutes any more. It just works.
- Except for those times Microsoft shipped Windows Updates that force-updated people’s NuGet package binaries using the GAC. Fortunately, this won’t be a problem going forward as the GAC starts to disappear and strong naming becomes a thing of the past.
- This is currently outstanding on GitHub. The naming of things has been a point of criticism.
- There was a long discussion on GitHub about the k* names.
- At some point more betas are going to come along. One problem with some of the beta packages is they are still in flux. Be careful when upgrading packages from one beta to another, it can break things even in other packages.