Skip to content →

ASP.NET vNext, How & why? (Notes)

 

What is ASP.NET vNext?

  • New flexible and cross-platform runtime
    • Run it on Windows
    • Run it on Mac
      • Using Mono
    • Run it on Linux
      • Using Mono
  • Modular HTTP request pipeline
    • No more System.Web
    • Baremetal performance
    • Supports OWIN
  • Built cloud ready
    • Fully self contained, not coupled to .NET framework
    • Slimmed down to a CoreCLR
    • Use only the components of the baseclass library that you need using Nuget
    • Side by side deploy
    • No GAC or binding policies
  • Friendly frameworks
    • All references pulled in using Nuget at runtime
  • Agile development with the tools of your choice
    • Visual Studio 14
      • New project system that removes the “build” set between code & F5
    • Command line – Full Command line support
    • 3rd party editors – Sublime support
  • Open source on GitHub

In an effort to create an experience as close to Ruby & NodeJS ASP.NET vNext will do build compilation at run time unless you choose to do pre compilation.

Inversion of Control

You apps will be fully componentised and provisioned from the ground up using the inbuilt “inversion of control” (IoC) container.  Providers are not configured in Web.config any more but are replaced with a IoC, you can rip out the provided one and use your own.

Take away: If you are already using an IoC (Castle Windsor, Autofac) you will be in a good position here, however the recommendation is to start using one.

Bower & Grunt

Although many people have been publishing front-end frameworks using Nuget e.g. AngularJS, JQuery etc, Nuget is not great at managing the content files. Rather than extend Nuget the team have taken the decision to implement first class support for Bower & Grunt.

Take Away: This functionality has already been packaged into a number of Visual Studio extensions so that you can start adopting this work flow with Visual Studio 2013, alternatively you can use the Bower Nuget package.

Using Environment Variables for identifying configuration

Rather than compile and package for application for each environment and run the associated web.config transforms, ASP.NET will now use a preconfigured Environment Variable to determine which environment it is running in and make associated configuration changes. We can already do this today by creating our own Environment variables and querying them at run time.

No web.config – replaced with your own providers e.g. Json file, environment variables and IoC for provider configuration

Deep integration with Roslyn & Nuget

Real-time compilation and debugging enables whole new code-debug-run scenarios, especially when it comes to 3rd party references. Examples of cloning via git, referencing and compiling where given in talks that represents a much fast and open developer cycle than the more common use of published, compiled binaries.

Take away: keep on track with understanding Roslyn, no need to go into deep understanding but keep playing with it.

Harmonised frameworks

Web Pages, MVC & WebAPI have all been harmonised together

MVC + WebAPI + Web Pages = ASP.NET MVC 6

Both Web Pages will now be built on the same basics as MVC & WebAPI. Web Pages will have a clear upgrade model to MVC.

Moving forward – Compatibility

Web Forms, MVC 5, Web API 2, Web Pagaes 3, SignalR 2, EF 6

Fully supported on .NET vNext (NOT ASP.NET vNext)

MVC, Web API, Web Pages 6, SignalR 3

Run on new runtime and request pipeline only (no System.Web.dll)

To migrate MVC app, you will have to create a new project and migrate!!!!

Cloud Optimised RunTime

Very slimmed down version of CoreCLR, could take a while!!!

API portability scanner to find out if your code will port

 

RTW Release Q2 2015

References

Published in ASP.net

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *