ASP .NET 5

 ASP .NET 5

                   

ASP.NET 5 stack only offers MVC as the paradigm to build HTML views. Existing Web Forms pages are not supported.

The file system has been abstracted too and this is the key step to having ASP.NET 5 solutions potentially hosted on any platforms that understand and support .NET. ASP.NET 5 can run on three different runtimes: full .NET CLR, CoreCLR on Windows, and cross-platform CoreCLR on Linux and Mac systems. You can host ASP.NET 5 applications even on an Apache Server running on a Linux machine.

Roslyn overtakes the historical CodeDOM API. Roslyn is also ideal for the dynamic compilation of Razor views. Roslyn is faster because it always operates in-process and doesn’t require configuration. Using a Mac computer to edit the code and uploading to a real server or virtual machine to test—no MSBuild, no Visual Studio, just a plain text editor. You no longer have the strict need to package and deploy assemblies to the server.


You get a smaller footprint than with today’s full-blown .NET Framework. ASP.NET 5 has no dependency on system.web. Among other things, this means that the memory footprint for an HTTP request is cut from about 30K of today’s HttpContext graph to about 3K of the analogous graph in ASP.NET 5.


2 versions of the .NET Framework in Visual Studio 2015:
   1) .NET Framework 4.6  (minor improvements to Web Forms, WPF, Windows Forms).
   2) .NET Core 5 (bunch of libraries have been removed and other refactored to cut dependencies) (1/10 size of full version)
  Both versions of the .NET Framework share the same garbage collector and the new 64-bit JIT, known as RyuJIT.

First and foremost, the .NET Core 5 framework is open-sourced to GitHub .
Second, the framework will be ported to foreign platforms such as Linux and Mac.


In ASP.NET 5, you’ll find a slightly improved version of ASP.NET MVC (called ASP.NET MVC 6) that runs in the same pipeline as Web API and ASP.NET SignalR and, for this reason, breaks up binary compatibility with Web Forms.  No significant new programmatic features. The major benefits are in the resulting performance and overall memory footprint.

By using a CQRS architecture in the design of your ASP.NET solution—namely by separating query and command stacks—you can optimize each stack separately and more easily consider, at some point, deploying query and command stacks as different sites.


Overall, I see five cases for a technical manager to consider:
1) Plain Web Forms applications
2) Web Forms applications being the container of Silverlight or client-side components calling into WCF endpoints
3) ASP.NET MVC applications generating HTML on the server and optionally serving as the container of some client-side components bound to HTTP endpoints
4) Web Forms applications being slowly migrated to ASP.NET MVC
5) Thin HTML5 containers consuming Web API endpoints

If you have the budget and the need, go straight to ASP.NET 5 and CoreCLR.

Device-friendly. In this regard, the good news is that ASP.NET MVC already incorporates a little known feature called display modes.
A display mode adds a condition on top of the view engine and takes the view engine to select a particular display mode for each
given Razor view.

===============================================================

    ASP.NET 5
    Entity Framework (sub-project of ASP.NET 5)
    ASP MVC (sub-project of ASP.NET 5)
    Razor View Engine (sub-project of ASP.MVC)
    Signal R
    Azure SDK
    The Rosyln Compiler

===============================================================

ASP.NET vNext leaves behind:
   WebForms,
   ASMX Web Services,
   ASP.NET AJAX,
   WCF REST,
   HTTP Pipeline,
   HttpModules,
   HttpHandlers
   ASP.NET Web API

Merges features of ASP.NET Web API with ASP.NET MVC framework

two runtime modes: Full CLR ( full .NET 4.5 Framework runtime ) and the light weight Core CLR.
Full CLR is running nearly twice the memory footprint as the Core CLR.
The Full CLR is also tied to Windows with its dependency on the full .NET 4.5.x Framework
  and any xcopy deployment will at least require the existence of .NET 4.5.x in order to run.

Core CLR was originally used in Silverlight, but this version includes only server-relevant
features geared at building Web applications.

No WPF, WinForms, WCF, or Workflow in Core CLR.

Core CLR requires that you use newly compiled Core CLR-compliant NuGet packages.
At the very least, that any existing library has to be recompiled.

Conditional compile:  #if ASPNET50CORE  

Because the Core CLR is a trimmed-down version of .NET, it’s small enough that you can ship it with your
application as a distributable or as a system-installed component in a well-known, centralized location
that is cached. You no longer have to depend on a system-provided runtime version, but you can ship the
exact version you require right alongside your application.

ASP.NET vNext is built from the ground up using task-based asynchronous semantics.

Developers need to learn async/await code in your Web application code.

ASP vNext removes the dependency on the System.Web assembly. Built with much more modular fashion.
Using components, you get to choose exactly what features you want to support and load into your
application rather than getting "everything and the kitchen sink," as with System.Web.

The hosting framework is also decoupled from IIS and the ASP.NET core components.

Open Web Interface for .NET (OWIN) inspired extensibility and configuration in this project.

The model consists of a startup configuration class and method that has various extension methods for middleware (the new term for modules). Middleware registers itself through configuration extension methods that are called to configure the middleware component. Then a very simple middleware interface that consists of a single async method with a callback to the next method is used to hook into the vNext execution pipeline. These middleware delegates are chained together by vNext to handle the processing flow for each request. Unlike classic ASP.NET, there are no specific events to hook into. Rather, the order of hooking up the components determines the order in which these middleware components are executed. The middleware interface is simple: It receives a Context and a pointer to the next task to execute in the chain. Each middleware component can handle both the inbound and outbound request processing in a single component.

Middleware components are asynchronous by default, so any extension point has to be created using async method semantics.

Today, we have several different frameworks that sit on top of ASP.NET: Classic System.Web based applications (WebForms/Handlers/Modules/ASMX etc.), MVC (based on System.Web as well), Web API (based on its own stack), and SignalR (OWIN based stack). Each of these frameworks has its own bootstrapping and hosting logic that is different and duplicated.

New way combines MVC, WebPages, and WebAPI into a single framework. This combined framework can take advantage of Content Negotiation and REST-based controller discovery using HTTP verb semantics, as well as handle View rendering using the Razor View Engine. Essentially, you get the best features of both MVC and WebAPI in a single unified framework that can handle both API and HTML endpoints seamlessly—even in the same controller. This mix–and-match opens up a number of new scenarios.

New way offers a no-compilation workflow where you can make changes to source code and see the changes reflect as soon as you refresh your HTTP content.

Introduces the concept of a Web root (named wwwroot by default)

Separates your code from the final website completely so that only your actual Web content is accessible via the Web.

No direct dependency on MsBuild to build/package a project.
Applications are built using the K Package Manager: KPM.

There are no assembly references in vNext, only NuGet package references.
Also there are two nodes there: ASP.NET 5.0 and ASP.NET Core 5.0, which corresponds to the two supported build targets of the Full CLR and Core CLR.

IIS isn’t required to run ASP.NET vNext applications and self-hosting is built-in.

Self-hosting is useful for many development and administration portal scenarios, but for building high-end server applications, I would still recommend that you stick with IIS whenever performance, security, and administration matters. A ton of infrastructure (like Web Deploy, Application Initialization, ApplicationPool crash recovery, Load Balancing, etc.) is built into the IIS platform and you’d just be pushing those tasks into your application when you forego running on IIS.

In vNext, there’s no .config file-based configuration. Instead there is a new non-hierarchical configuration provider that can load configuration settings from various different sources, including JSON, INI files, and the system Environment.

PROBLEMS:
The biggest problems I ran into had to do with finding my way around the new NuGet packages and namespaces.
Solution - To help with this, Microsoft has created a simple helper site that you might find useful: http://packagesearch.azurewebsites.net/. Using this tool, you can type in the name of a class or namespace and it returns the packages and namespaces that match.

It’s more difficult to follow program flow without actually running an application.

Another pain point in this project was Entity Framework 7, which has a number of missing features at the moment.