At TechEd, Microsoft took the wraps off of the new ASP.NET server-side components in a package they're calling ASP.NET vNext. Formerly, this was called Project K, and you'll see some insiders use both of these terms for the next few months. This project contains some very exciting capabilties for web developers, and the promise within the coming changes is impressive.
OWIN, the Open Web Interface for .NET is taking over the ASP.NET runtime. Microsoft is embracing the open standard of constructing and assembling web components, and allowing you to assemble as opinionated or flexible a web stack as you need. Web projects now have access to an immense collection of building blocks, and you can assemble them any way you would like.
ASP.NET MVC vNext is now OWIN compliant. That means you can run MVC applications on a very thin Katana server, or on a Project Helios managed IIS instance. These are amazing choices that you can make, as you no longer will be obligated to load packages and assemblies that you don't need for your application.
Web Applications will now be delivered with 4 distinct layers:
- The host application - in the past this was ALWAYS Microsoft Internet Information Server (IIS). This could be IIS, IIS with Helios, Katana, or some other OWIN capable host.
- The CLR framework - previously you would choose which version of the Microsoft.NET framework you wanted to use. This may be .NET 4.5.2, K runtime, or Mono.
- The Application Host - previously, this would be the W3C executable. Now, this can be a host for the Visual Studio designer, or the new Microsoft.Host.Runtime.
- Your Application - Your application now loads the former ASP.NET frameworks (MVC, WebAPI, or SignalR) as part of its dependencies.
MVC - Meet WebAPI, WebAPI meet MVC
If you've been working with ASP.NET for a few years, you've no doubt noticed that the MVC and WebAPI frameworks are very similar. In fact, they use the same Controller syntax, with WebAPI responding to controllers actions that are named like HTTP Verbs. In the next version of ASP.NET, this mix-and-match scenario goes away. There will be one framework that provides this Controller-centric server-side capabilities. All of these capabiltes are housed in the new Microsoft.AspNet.Mvc framework.
Bye Bye System.Web
Alas after 15 years, we say goodbye to System.Web. We knew you so well....
To some, this is a welcome departure as the System.Web assembly is the second largest assembly in the base class library (BCL). This 5 megabyte monster was very difficult for the ASP.NET team to manage, and any changes to it required an update to the .NET BCL. Those changes are not deployed easily, and typically only ship with a new Visual Studio or a new version of Windows. In order to keep the ASP.NET run-time more nimble and adapting at the speed of the Internet, the ASP.NET team decided to move all new development out of System.Web.
This also means that ASP.NET web forms is not coming along for the ride into ASP.NET vNext. This does not mean that they will stop maintaining it. It does mean that the changes to it will not be as quick, and that you can still use Microsoft IIS to host your web forms application. None of that has changed or will change for a very long time.
The demonstrations on stage at TechEd were nothing short of impressive. Granted, the demos that are currently being shown are very small. The compile and execution time of the code is amazing. In fact, you don't have to compile at all. The Roslyn compiler will automatically make those changes and deploy them for you when the code files change!
Where is web.config?
Configuration files? Who needs configuration files! The .config file architecture was an artifact of the System.Web library. At this point, why write a configuration file when you can hard-code your configuration in C# code and Roslyn will reload it faster than you can say "I saved a change to the configuration." Look for a new configuration standard to come along soon, and it will probably be based on JSON, given the new project.json file structure. Which brings us to...
No more XML .csproj nonsense with build artifacts and configuration defined. In this next version of ASP.NET, we will have a JSON file that lists our dependencies, the configurations we want the application to run in, and the commands that we can use against the web application.
Dependencies are kicked up a whole new level, as they no longer require a compiled DLL to reside on disk. You can now add references to NuGet packages, and ASP.NET will fetch that dependency when you first deploy and run your application. This allows you to compose your application from more NuGet building blocks, and adhere to those SOLID principles).
Project.json has a syntax structure similar to the following:
You can force your project to download and run with the NuGet packages specified in your project.json file with this syntax:
What does this mean for Telerik UI Customers?
At this time, we are eagerly watching the evolution of ASP.NET, and think this is going to be an amazing product for our customers. We will make whatever changes we need in order to support our MVC helpers in this new ASP.NET. Additionally, we will continue to support and add cool, modern and mobile functionality to our UI for ASP.NET controls.
At Telerik, we are very excited about the changes being introduced by Microsoft in this next generation of ASP.NET. We will be there for you as this project from Microsoft moves towards completion. Its all part of Telerik's commitment to support any software development in any development environment and targeting any screen.