Introduction to ASP.NET vNext

In the next version of ASP.NET we are working with multiple teams around Microsoft to create a lean, composable .NET stack that provides a familiar and modern framework for web and cloud scenarios.

This new stack will consist of:

• A small .NET Framework that is split into a number of pay-for-play packages
• A unified web stack built on top of the small core
• Simple packaging/versioning/servicing rules
• True side-by-side, such that two applications running different versions of the CLR can run SxS on the same server without conflicting with each other

Runtime

What is the .NET Execution environment (DNX)?

The DNX is an SDK containing all of the bits needed to build and run an application, including the CLR in the case of Core CLR. It can be bin deployed with your application and as such can be deployed SxS with other applications on the server.

The DNX contains some utilities, such as dnu to do building and packaging of your application, as well as hosts that can boot a CLR and provide an environment for your code to run in. You can see the structure and components of the DNX here.

Defining a project

When working on the new stack the main project definition happens in a project.json file. This file is designed to be human readable and contain all information required for theruntime to run your application. This includes the metadata about your project like the name, version, etc as well as the list of dependencies, commands that can be run, and some other information. It doubles as a nuspec and packages.config.

What it doesn‘t include is anything from tooling, like VS settings, user specific settings, etc. The settings and information required by Visual Studio are still stored in a project file, similar to the csproj files we have today, and not in the project.json files. There should be no duplication between the two files, and the project.json should be all relevant and specific to your application.

Much of the project.json file can be inferred by the runtime, such as using the name of the directory as the project name. The intent is to provide a file that has only useful information in it and maintains the ability to be read and understood so we want to keep the clutter to a minimum.

Dependencies

Dependencies are defined using only a name and version:

"dependencies": {
  "Microsoft.AspNet.ConfigurationModel": "0.1-beta4-*",
  "SomeProject": "1.0.0"
}

There is a loader chain the runtime uses to determine what it needs to load when resolving a dependency. For example, one of the loaders will look for a NuGet package with the given name, another will look for a project that it can compile (another folder with a project.json), and another will find assemblies on disk.

One of the goals of this effort was to make a NuGet package the primary unit of reference, it is expected that all dependencies end up as either NuGet packages or project references.

One of the scenarios this allows is the ability to depend on a NuGet package, and then later clone the source into your project and use source without changing anything in your project. This significantly reduces the friction of debugging and fixing a library you have source for.

Core CLR

Part of this effort is a slimmed down .NET Framework optimized for server and cloud. What this means in practice is that you will depend on Core CLR, a small SxS capable CLR, as well as a number of NuGet packages with libraries you want to use. For example, none of the XML APIs are part of Core CLR. To use them you can add a dependency to one of the XML packages that has the functionality you need.

Build vs. Run

We‘ve mentioned a couple of times that dependencies can be a directory of source that the runtime can compile. This is done with Roslyn. If a runtime needs a load a project then it is capable of using Roslyn to compile the project and load the generated assembly. One important aspect of this compilation is that it never writes an assembly to disk, and when you build instead of running all you are doing is persisting the same thing to disk. There is no difference between build and run, other than the output of an assembly to disk.

Frameworks

MVC

Built on top of the runtime features described above is a new unified web stack. We are merging MVC, Web API, and Web Pages into one framework that includes:

• One routing system, one model binding system, one filter pipeline, etc.
• Smooth transition from Web Pages to MVC
• Return HTML as views or data

SignalR

ASP.NET vNext includes support for the real-time Web through the next version of ASP.NET SignalR.

Data

For Data we are building a lighter weight version of Entity Framework that can be used across a wide variety of platforms. This effort is not about re-implementing the entire EF stack; the current stack contains a lot of APIs and features that are not especially useful and/or hardly ever used. The lighter weight version will be simplified so that it doesn’t contain these. Some examples of this simplification include just having the DbContext API (no ObjectContext API) and supporting a reduced set of mapping patterns. You can read more about the plans for EF here.