Skip to content →

Month: October 2014

ASP.NET vNext – Webroot, static content and client side serving (Notes)

Notes from the ASP.NET vNext community stand up.

Web Root, Static Content and client side serving

A new project sub-folder that is the route folder that your webserver hosts e.g. IISExpress would point to the WebRoot folder no instead of the Project Route. Within this folder you will place all the static content that would get served by the webserver. The purpose of this folder is to provide better security and better support for a front end build process. Therefore this folder is where the output of any frontend build process using Gulp, Grunt or Bower would go. It can be thought of as the bin folder for static files and WebRoot can be viewed as

If you have moved to using bower to manage your front end assets, then you would have a task runner to copy your assets from bower_components to the WebRoot.

WebRoot would not be checkedin to your source control folder, as its built as part of the build process.

This is a very common pattern for Ruby & NodeJS developers.

Build orchestration on Windows within Visual Studio will use new project file type, appname.kproj which is an MSBuild file for Visual Studio, however MSBuild is not used for compilation as compilation is done at run time.

 

Publishing processes within Visual Studio to compile and build a package for publishing use the KPack solution.

Recommendations

  • Build out a front end build process using Grunt, Gulp and Bower.
  • Move minified/transformed content files from bower_components to a separate content folder

Reference

https://www.youtube.com/watch?v=fNJ70gRmPWU&list=PL0M0zPgJ3HSftTAAHttA3JQU4vOjXFquF&index=6

Leave a Comment

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

Leave a Comment