Home

##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 KRuntime?

The KRuntime is an SDK containing all of the bits needed to build and run an application. It can be bin deployed with your application and as such can be deployed SxS with other applications on the server.

The KRuntime contains some commands, such as k.cmd that allows you to do k build, and the default loaders and other pieces required to compile and run your app. You can see more of the structure and components of the KRuntime here.

##Defining a project

Projects on the new stack are a little different to what you used to have. 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 the runtime 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. In the future there will be the first class Visual Studio experience that you get today, with some new features. But the settings and information required by these tools will be 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. But for now we only have the runtime and command line to work with.

If a directory has a file called project.json in it, then the runtime will assume that directory contains source that can be compiled and run. Some of the information in the project.json is worked out by convention, the directory name being the name of your app for example. So the minimum required to get source compiled by the runtime is a folder with a project.json file that contains valid json, which means empty curly braces. Of course, in practice, your application will not be able to do much without some dependencies.

##Dependencies

Dependencies are defined using only a name and version:

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

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.

We are still working on the experience of this. We want to provide as much pay-for-play as we can, allowing you to pick which pieces of the framework you need to use and nothing more. But there is also a desire to not make it impossible to find what I need to use. We are planning a layer of meta packages that would group commonly used packages together to make it easier to depend on a chunk of functionality.

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. so there is no difference between build and run, other than the output of an assembly to disk.

#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

#Data

For Data we are building a lighter weight version of EF 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