Slides from my presentation at Webstep on October 9th, 2014.
The following information is based on ASP.NET vNext alpha4 and Visual Studio "14" CTP4.
There are two main areas of .NET development. The first is Client development, with Windows Store apps, WPF apps, Windows Forms applications, Console applications and various libraries.
The other area is Web development, with technologies like Web Forms, MVC, ASP Web Pages, Web API, SignalR and WCF. This is the topic of this talk.
The coming version of ASP.NET vNext will use a now have new CLR host, which will support three different runtimes.
The .NET CLR will still be supported, and will give best compatibility with existing codebase. This will require .NET to be installed on the machine hosting the application, like we are used to.
Core (cloud optimized) CLR is a slim and refactored runtime, made to support more modern deployment scenarios, with multiple applications being hosted on the same web server. The CoreCLR is fully self-contained, and is basically a bunch of NuGet-packages that will be deployed together with the application.
Mono CLR is a runtime for running on Mono (OSX/Linux). Mono has earlier not been supported by Microsoft, and has been a "good luck" kind of deal. This is changing now, and Mono is the official way of running .NET code on OSX and Linux. The development is still in Xamarin's hands, but this time in partnership with Microsoft.
The new CoreCLR is as mentioned slimmed down as much as possible. It does not support Winforms, WebForms, WCF, WIF, WF.
The API is "Modernized", meaning it has changed a bit, in order to remove unwanted dependencies. Microsoft will provide a tool for checking if your application is compatible with the CoreCLR, or which API calls you need to change.
The CoreCLR supports packaging the framework dependencies as NuGet-packages with your application, which enables full side-by-side deployment. Meaning you now can have multiple apps running on different versions of the .NET runtime on the same computer. Currently, a bare MVC6 application packaged with the CoreCLR runtime and the default libraries is around 100MB.
The request pipeline now is changed to include a bare minimum of functionality. If you want to serve static files, this is something you have to explicitly opt-in to. This gives a dramatic improvement to speed of request handling, more similar to Node.js.
This speed increase is achieved by removing the old System.Web dependency of ASP.NET, which had to have full backward compatibility with things like ASP Web Pages.
An HttpContext object graph can today take up to 30KB of memory pr request, in MVC6 it is around 2KB.
ASP.NET vNext aims to reduce friction of deployment, with an improved environment variable based configuration system. You can register multiple configuration providers, so you can have settings in a config.json file for local development, while falling back to environment variables when deploying to staging and production environments.
The ASP.NET MVC and WebApi frameworks are today very similar, with both having Controllers, Actions, Filters, Model binding and Dependency Injection. Unfortunately they have different implementations of these concepts, contained in different libraries.
In MVC 6 we get a unified framework, with the functionality of MVC, Web API and Web Pages in the same components, simplifying the use of MVC and Web API in the same application without lots of code duplication.
MVC6 can both be hosted in IIS (using something like project Helios) or self hosted in an application host like Katana (which was an early OWIN implementation/experiment by Microsoft).
MVC6 supports well known frameworks like SignalR, Identify Foundation, Entity Framework.
Visual Studio "14" will have features of ASP.NET vNext tightly integrated, with automatic downloading and referencing of libraries when editing the project.json-file.
In addition, there will be full feature parity with command-line tools. So everything you can do in Visual Studio you should also be able to do in the command prompt, both in Windows and in OSX/Linux.
The new project.json merges files like packages.config, NuGet specs (.nuspec) and projectfiles (.csproj), to contain all the information concerning the current project.
The project.json file should not contain anything editor-specific, so files like .csproj or similar will sitll be created by IDEs, but these files might not be something you want to check into version control.