Page 14 - MSDN Magazine, May 2017

Figure 2 Fundamental Differences Between Flavors of ASP.NET Core
Webserverthatreceivesrequestsandtriggerstheinternalapplication pipeline to have them processed. The following code does the job:
var host = new WebHostBuilder()
.UseKestrel() .UseContentRoot(Directory.GetCurrentDirectory()) .UseIISIntegration()
.UseStartup<Startup>()
.Build(); Host.Run();
Kestrel is the name of the ASP.NET Web server that receives inbound requests and processes them through the pipeline. The IIS Integration module call in the code snippet is only required if you host under IIS.
Having a reverse proxy around the ASP.NET Core application is recommended primarily for security reasons as the Kestrel internal Web server doesn’t include (at the moment) filters to prevent things such as distributed denial of service (DDoS) attacks. From a purely functional point of view, you don’t strictly need a reverse proxy enabled.
Kestrel is the name of the ASP.NET Web server that receives inbound requests and processes them through the pipeline.
As mentioned, there’s no longer a global.asax file in an ASP.NET Core application and the role of the web.config file is wildly dimin- ished. Actually, it only serves the purpose of enabling IIS to do some work on behalf of the application, such as serving some static error pages. Key things such as configuring error handling, log- ging, authentication and storing global configuration data are done through a new API orchestrated from the startup class.
The Startup Class
The startup class contains at least a couple of methods that the host will call during the initialization phase:
public class Startup {
public void ConfigureServices(IServiceCollection services) public void Configure(IApplicationBuilder app)
{
Framework
Facts
.NET Framework
ASP.NET MVC only; no WebForms
New runtime environment and programming API Any libraries targeting the selected version of the .NET Framework
Only IIS hosting
.NET Core
ASP.NET MVC only; no WebForms
New runtime environment and programming API Only .NET Core libraries
Cross-platform hosting
Regardless of the choice of the .NET Framework, going with ASP.NETCoreexposesyourcodetoanewruntimeenvironment that unifies the MVC runtime based on system.web with the Web API runtime inspired by the OWIN principles.
Breaking Up with IIS
In recent years, the Web API framework attempted to address the high demand of thin servers capable of exposing a RESTful interface to any HTTP-enabled clients. Web API decoupled the application model from the Web server and led to the OWIN spec- ification, namely a set of rules for Web server and applications to interoperate. Web API, however, needs a host and when hosted in the context of an ASP.NET application, it just adds another runtime environment to the memory footprint. This happens at the same time in which the industry is moving toward super-simple Web. A super-simple, minimal Web server is an HTTP endpoint to get content as quickly as possible, just a thin HTTP layer around some business logic. All that a super-simple server needs to do is process the request as appropriate and return a response with no overhead except for the business logic.
Although customizable to some extent, the current ASP.NET runtime environment wasn’t designed to address similar scenarios. Separating the ASP.NET environment from the hosting environ- ment is the key change you find in ASP.NET Core and the reason for many of the subsequent application-level changes.
Startup of an Application
After creating a new project, the first thing you notice is the lack of a global.asax file and the presence of a program.cs file. As shocking as it might be, an ASP.NET Core application is a plain console application launched by the dotnet driver tool (bit.ly/2mLyHxe).
The dotnet tool is the key to multi-platform support. Once the command-line tool (and the .NET Core framework) is available for a new platform, hosting reduces to connecting the Web server to the tool. Under IIS, publishing is accomplished through an ad hoc module, the .NET Core Windows Server Hosting pack-
age (bit.ly/2i9cF4d). Under Apache, on an Ubuntu
server, it’s achieved through a configuration file.
An example can be found at bit.ly/2lSd0aF.
app.Run(async (context) => {
await context.Response.WriteAsync(DateTime.Now) });
}
Through the ConfigureServices method you declare the system services the application will use. Technically, the method is optional, but I’d say that one is necessary in any realistic scenarios. To a
}
ASP.NET Internal Server (Kestral)
Middleware Middleware Run {...}
The actual Web server works as a reverse proxy and communicates with the console application over a configured port. The console application is built around another, simpler,
Reverse Proxy
Figure 3 The ASP.NET Core Middleware
10 msdn magazine
Cutting Edge