DNX Framework Choices and ASP.NET 5

You can think of an ASP.NET 5 application as a DNX application, where DNX stands for .NET execution environment.

And the projects we create with a project.json file? These are DNX projects. The DNX is not just a runtime environment, but also an SDK.  Conceptually, I think of the new world like this:

The DNX gives us the ability to cross compile a project across different renditions of a Common Language Runtime, and then execute on a specific variant of a CLR. We can compile against a full CLR, or a core CLR, or both. The compilation settings are controlled by the frameworks property in project.json.

"frameworks": {
  "dnx451": { },
  "dnxcore50": { }
}

The monikers to choose from currently include dnx451, dnx452, and dnx46 for a full CLR, or dnxcore50 for a core CLR. At execution time the code must execute against one of the targets specified in project.json. You can select the specific DNX environment using the project properties –> Debug tab in Visual Studio and run with or without the debugger.

You can also use dnx from the command line to launch the application after selecting an environment using the .NET version manager (dnvm) tool. The following screen shot is showing how to list the available runtimes using dnvm list, and then configuring the 64 bit variant of the Full CLR, beta 7 version as an execution environment.

After the above command completes, the dnx we’ll be using will be the dnx from the folder for the 64 bit variant of the Full CLR, beta 7 version, and any application launched using dnx will use the same.

Choosing

“Which environment is right for me?” is an obvious question when starting a DNX project. What follows is my opinion.

Choose Both

In this scenario, we’ll include both a core CLR and one version of a full CLR in the frameworks of project.json.

"frameworks": {
  "dnx46": { },
  "dnxcore50": { }
},

This choice is ideal for projects with reusable code. Specifically, projects you want to build as NuGet packages and consume from other DNX applications. In this scenario you won’t know which framework the consumer might need to use.

This choice also works if you haven’t made a decision on which CLR to use, but ultimately for applications (not libraries), I would expect to target a single framework.

Choose The Full CLR

In this scenario, we’ll specify a only a full CLR in the frameworks section.

"frameworks": {
  "dnx46": { },
}

Targeting a CLR for development and deployment gives you the best chance of compatibility with existing code. The full framework includes WCF, three or four types of XML serializers, GDI support, and the full range of reflection APIs. Of course, you’ll only be developing and running on Windows machines.

Choose the Core CLR

In this scenario, we’ll specify a only the core CLR in the frameworks section.

"frameworks": {
  "dnxcore50": { }
}

With the core CLR you can develop and deploy on Windows, Linux, and OS/X. Another primary advantage to the core CLR, even if you only run on Windows, is the ability to ship the framework bits with an application, meaning you don’t need a full .NET install on any server where you want to deploy. In fact, you can even have multiple applications on the same server using different versions of the core CLR (side-by-side versioning), and update one application without worrying about breaking the others. One downside to using a core CLR is how your existing code might require framework features that do not exist in the core. At least, features that don’t exist today.

Summary

I expect the core CLR will have a slow uptake but eventually by the primary target for all DNX applications. The advantages of going cross platform and providing an xcopy deployment of the framework itself will outweigh the reduced feature set. Most of the sub-frameworks in the full CLR are frameworks we don’t need.