有关Hosting的基础知识 

    Hosting是一个非常重要，但又很难翻译成中文的概念。翻译成：寄宿，大概能勉强地传达它的意思。我们知道，有一些病毒离开了活体之后就会死亡，我们把那些活体称为病毒的宿主。把这种概念应用到托管程序上来，CLR不能单独存在，它必须依赖于某一个进程，我们把这种状况称之为：CLR必须寄宿于某一个进程中，而那个进程就是宿主。

   ASP.NET Core的一个大的改变就是就是将Web应用程序改成了自寄宿。什么意思呢？我们知道，在之前的ASP.NET版本中，ASP.NET的Web应用程序都是深度依赖IIS和Windows Server，以至于ASP.NET只能在Windows Server上运行。之所以出现这种情况，就是应为我们开发的所有Web应用程序都是寄宿在IIS进程中的。一般来说，一个进程只能加载一个CLR（不同进程之间可以加载不同的版本的CLR），为了托管多个Web应用程序，IIS使用了应用程序池这种东西来模拟进程的行为，从而为不同的Web程序加载不同的运行时来托管它们。

    有关CLR和寄宿的知识，如果有兴趣，可以参阅《CLR via C#》。

    我们可以查看一下以前版本的ASP.NET程序，它是没有Main()函数的，也就是说它没有程序入口点，不是单独的进程。对于应用程序开发来说，这个问题并不大，因为开发者在意的Web程序的逻辑、数据安全等问题，而不是应用程序如何被加载。但对于一个Web框架来说，这个问题非常严重，因为它高度依赖IIS和Windows Server，减少了它的适用范围。如果我们查看ASP.NET Core的程序，你会发现它本质上就是一个控制台程序，如果我们把那些在Main()函数中自动生成的代码都删掉（VS2015的模板会自带一些代码），加上Console.WriteLine("Hello World!"); 它就会在控制台中打出Hello World！由于ASP.NET Core的程序自身有程序入口点，所以自身就是一个进程，它可以为自己加载合适的CLR来运行Web应用，这种情况就是自寄宿。这么做的最大的好处就是可以脱离IIS，从而脱离Windows Server的桎梏。只要对应操作系统上有符合CLR规范的运行时，那ASP.NET Core的应用就可以部署在那个操作系统上。.NET Core里包含了微软开发的跨平台CLR运行时，可以运行在Windows，Linux和OSX上，借助它ASP.NET Core的应用程序就可以部署在这些操作系统上。

    说到这里，就只能下最后一个问题，IIS还扮演什么角色？当应用部署在Windows上时，微软推荐将IIS通过ASP.NET Core Module(之前的HttpPlatformHandler)模块作为Web应用的反向代理服务器(reverse-proxy server)。这个服务器的作用就是将请求转发到Web应用真正的服务器：

    服务器的问题会在下一篇文章中说明。前面上了那么多开胃菜，终于可以上正菜了。以下出现的所有源码都可以在Microsoft.AspNetCore.Hosting项目中找到。

Main函数里发生了什么

    如果新建一个ASP.NET Core应用，那么最先和我们打交道的就是Main函数中的WebHostBuilder，我们先来看看它的源码：

WebHostBuilder : IWebHostBuilder 3 { IHostingEnvironment _hostingEnvironment; List<Action<IServiceCollection>> _configureServicesDelegates; List<Action<ILoggerFactory>> _configureLoggingDelegates; IConfiguration _config = new ConfigurationBuilder().AddInMemoryCollection().Build(); 9 private ILoggerFactory _loggerFactory; 10 private WebHostOptions _options; IWebHostBuilder UseSetting(string key, string value) 14 { 15 _config[key] = value; ; 17 } 18 public IWebHostBuilder ConfigureServices(Action<IServiceCollection> configureServices) 19 { 20 _configureServicesDelegates.Add(configureServices); ; 22 } 23 public IWebHost Build() 24 { hostingContainer = hostingServices.BuildServiceProvider(); host = host.Initialize(); host; 33 } 34 //在这个方法中，_options会根据_config字段生成，StartUp类会以IStartUp->StartUp的形式注册到依赖注入容器中，即使StartUp不实现接口 IServiceCollection BuildHostingServices(){...}

     在每个ASP.NET Core程序的Main函数里面，都有很多UseXXX()的扩展方法，这些方法最终会调用WebHostBuilder.UseSetting()或者ConfigureService()方法。这两个东西的区别在于，_config里面存的东西是每个Web程序都有的部分，比如应用的根目录，StartUp类的程序集信息等等；而Service是Web应用的可选部分，比如UseKestrel()最终调用的是ConfigureServices，因为服务器并不是必须的，可以开发符合Owin规范的程序使应用部分和服务器部分分开来。还有一个区别在于_config中的内容比较简单，比如存储的应用根目录这些东西不必以服务的形式存在，当然有关StartUp的信息还是会以服务的形式注册到依赖注入容器。

    WebHostBuilder的这些信息最终会传给WebHost，注意构造WebHost之后，还调用了它的Initialize()方法。我们来看看WebHost类的源码。