An Introduction To ASP.NET vNext

ASP.NET vNext includes updated versions of MVC, Web API, Web Pages, SignalR, and EF. The key improvement with these frameworks is that MVC, Web API, and Web Pages have been merged into a single programming model. For example, there’s now unified controller and routing concepts between all three. You can now have a single controller that returns both MVC Views and formatted Web API responses, on the same HTTP verb.

ASP.NET vNext apps are cloud ready, by design. Services, such as session state and caching, adjust their behavior depending on whether the app is running in the cloud or in a traditional hosting environment, while providing a consistent API. We use dependency injection behind the scenes to provide your app with the correct implementation for these services. Using this approach, it is really easy to move your app from on-premises to the cloud, since our code changes, not yours.

You will be able to make changes to your web applications and see the results after a browser refresh, with no separate build step needed. This significant productivity enhancement is based on improvements to load times in the underlying CLR, as well as use of the new .NET Compiler Platform (“Roslyn”).

Why we Go to ASP.NET vNext,

Cloud-ready out of the box.
A single programming model for Web sites and services.
Low-latency developer experience.
Makes high-performance and high-productivity APIs and patterns available – enables them both to be used and composed together within a single app.
Fine-grained control available via command-line tools and standard file formats.
Delivered via NuGet.
Release as open source via the .Net Foundation.
Can run on Mono, on Mac, and on Linux.

ASP.NET vNext Features

NuGet Packages

ASP.NET - Monolithic assemblies
- Instead of shipping updates to the frameworks, in monolithic assemblies containing lots of functionality, in many years, the updates to the frameworks can be shipped in smaller nugget packages very frequently.
- Shipping updates using nuget packages has the least impact to the rest of the framework as a package contains only a specific functionality.
Cross Platform

ASP.NET - Coupled to the windows environment/IIS
- Though we can use Mono to run our applications on other platforms but only Xamarin was responsible for maintaining Mono.
  
  Also, configuring our applications for these platforms required a significant effort. We need to consider the mod_ mono/xsp/apache configuration.
  
  ASP.NET vNext - Designed as cross-platform and host agnostic
- Now, we can develop and deploy our ASP.NET vNext applications on different platforms, like linux. Also, we can host them on servers other than IIS. This is a significant change from the previous versions of ASP.NET.
- Microsoft now includes KRE for Mono so that asp.net vNext applications can run across different platforms.
- There are few things here that we need to understand when thinking about cross platform development.
  
  Mono is a “software platform designed to allow developers to easily create cross-platform applications”.
  
  KRE is a Run-time Environment used to execute ASP.NET vNext applications. It includes things like compilation system and SDK tools. We need to install KRE for Mono to enable cross-platform support in our applications.
  
  Command line tools and batch files: Because of the command line tools, we can do most of the things that we do in Visual Studio.There are batch files for important platforms, such as Linux. So, we are able to deploy our ASP.NET vNext applications without needing Visual Studio and Windows.
  
  KVM helps us retrieve different versions of the KRE and switching between them.
  
  project.json
  - Because of project.json file, we can open vNext projects outside of Visual Studio and we can even edit them using any text editor, such as notepad. This is a big change from project files, such as .proj file, in the earlier versions which were not very easy to edit without VS.
  - If we want to run our application on some other host other then IIS, such as self hosting, then we just need to change a single line of code in project.json . We need to use the package Microsoft.AspNet.Server.WebListener instead of Microsoft.AspNet.Server.IIS in the project.json file.
    
    So instead of the following dependency for IIS,
    1. "dependencies": {
    2. "Microsoft.AspNet.Server.IIS": "1.0.0-alpha4"
    3. }
    we need to use the below package for self hosting,
    1. "dependencies": {
    2. "Microsoft.AspNet.Server.WebListener": "1.0.0-alpha4"
    3. }
Open source

ASP.NET vNext- Fully Open Source
- MVC and Entity frameworks are open source and were available on Codeplex , in previous versions of ASP.NET. Now ASP.NET vNext is fully open source and it's code is available on GitHub. .NET Foundation is a forum for the development and collaboration of open source .NET technologies .ASP.NET vNext is part of .NET Foundation.
ASP.NET vNext Advantages
- Cloud-ready out of the box and it’s an open source.
- Dependency Injection: It’s built into vNext and is consistent across the stack.
- Cross-platform support: an active collaboration with Xamarin to ensure that cloud-optimized .NET applications can run on Mac or Linux on top of the Mono run-time
- You can make code changes in a .cs file without needing to build it.
- No longer dependent on Visual Studio. You can choose editors of your choice now, such as Web Storm, Sublime text.
- Modular Stack: ASP.NET vNext will ship as NuGet packages. Now you can choose what you want to keep
- MVC and Web API have been merged into a single programming model. It's a single programming model for building Web sites and services
ASP.NET vNext Disadvantages
- View compilation is always configured separately from your normal project compilation.
- View page errors don't show up in the IDE alongside normal compilation errors.
- Dependency Injection is different across all of our frameworks (Web API, MVC).
- MVC / Web API / Web Pages merge, using a common set of abstractions for HTTP, routing, action selection, filters, model binding.
- Each of our frameworks came to life at different times and all implemented their own version of dependency injection extensibility.