ASP.NET vNext is host agnostic, what does it deepl

According to ASP.NET vNext tutorial:vNext is host agnostic . You can host your app in IIS, or self-host in a custom process

Could anyone help me to understand this in deepth with showing the difference between current asp.net host and new one?

回答1:

The history of ASP.NET hosting

Back in 2002, there was basically one web server for the .NET platform, and that was IIS. A few years later the Visual Studio Development Web Server ("Cassini", formerly part of the original Web Matrix) came along as a dev-only server. But these all ultimately used System.Web as the hosting layer between the application and the web server. The System.Web host is tightly coupled to IIS and is very difficult to run on other hosts. Even the implementation on the VS Dev Web Server was limited because it supported only certain features. So as such, there was still just one production-quality "host" for typical ASP.NET applications that depended on System.Web.

Fast forward about a decade and OWIN came around as an interface between applications and web servers. This allowed any OWIN-compatible application to talk through OWIN to a web server that had an OWIN-compatible hosting layer. Microsoft wrote Katana as one OWIN implementation that could host ASP.NET Web API, ASP.NET SignalR, and many 3rd party frameworks on top of several servers, including IIS (and IIS Express), Katana's self-host server, and custom hosts (i.e. run Katana's host in a custom app). There's another OWIN implementation called Nowin that should be able to run the same apps as Katana. This is an example of host agnosticism.

Now fast forward another few years and there's ASP.NET vNext, which follows a model very similar to OWIN in terms of having middleware and having host agnosticism. ASP.NET vNext has compatibility layers for OWIN middleware app components as well.

ASP.NET vNext host agnosticism

ASP.NET vNext is host agnostic in the same manner as Katana and OWIN. Applications written using ASP.NET vNext only know about a host abstraction layer, such as the IApplicationBuilder (formerly IBuilder) interface. Applications do not talk directly to the web server. Much of this abstraction is done through "feature interfaces" so that some servers can implement features and others can choose not to.

Web hosting options

ASP.NET vNext applications can be hosted on IIS, IIS Express, your own custom EXE, in the new cross-platform Kestrel server, and no doubt more hosts in the future.

Neither Katana nor ASP.NET vNext are replacements for IIS or other hosts, though they do both have alternative web servers. IIS supports some more advanced features as compared to Katana and ASP.NET vNext, such as application warm-up, richer application lifetime management (i.e. what to do when the app crashes, controlling how much memory it uses, and other types of throttling), remote management, and so forth.

Benefits of OWIN, ASP.NET vNext, and being host agnostic

I can't speak to the motivations for creating OWIN because I was never part of that group. But the merits of having a web server host abstraction are many:

Can switch between hosts relatively easily. For example, it is common to locally run on a development-only server that can run with minimal permissions. Then upon deploying to production, perhaps a more full-featured host such as IIS is used. IIS, however, requires administrative permissions to install, which not everyone has on their workstations.
More hosting options can exist. Way back in the day because of the close dependency of ASP.NET on IIS only one host could exist, so there was effectively no "market" for other hosts.
Certain types of tests are easier to write by having an in-memory test host. This is used quite often to test the entire stack of a web application but without any network calls.

The motivations for ASP.NET vNext are listed in part on the official ASP.NET vNext site in the Getting Started tutorial. A brief summary is: to have a cross-platform, open source, side-by-side, pay-as-you-go, host-agnostic platform for building web apps and services. Sounds like some marketing stuff, but these are all key aspects of the system. NodeJS offers pretty much this same exact set of features, though of course once you look at the details, there are of course many implementation differences and no doubt some deeper philosophical differences as well. The motivations for supporting these features are generally self-explanatory.

Audience for ASP.NET

Note that this is about the audience of ASP.NET in general, which includes everything from ASP.NET Web Forms, to MVC, Web API, SignalR, Katana, and ASP.NET vNext. Any of these frameworks are suitable for any size project and should be usable by any reasonably skilled developer. This is evident by looking at the sizes of projects that use them. This very site (StackOverflow.com) is built in part using ASP.NET MVC, by some very advanced developers (I assume), yet there are many much smaller sites using MVC built by relative novices. ASP.NET vNext is the future version of most of these same frameworks, and as such it targets the same type of applications and the same type of developers.

More information

For some more info on ASP.NET vNext and OWIN, check out a blog post from one of the devs: http://whereslou.com/2014/06/10/asp-net-vnext-moving-parts-owin/

回答2:

Keeping in mind that vNext is still a very brightly coloured fast moving object, as things stand currently, it's kind of "half" host agnostic.

The middleware spec that it defines and applies does allow for a very generic interface for arranging programs. So the way you develop is the same. But vNext apps are themselves servers and in a strange way, are currently required to include glue libraries for the type of server you're using.

You can observe this by seeing that you must supply what type of server you want to use inside your project.json file. If vNext projects were truly agnostic, you would select a server at a systems level and point to, mount or launch your app from the chosen server.

It's somewhat complicated because of the lifecycles involved, after you're done here, I encourage you to head over to this github issue on the vNext project where I'm trying to advocate a truly decoupled design.