一、前言上一篇《asp.net core 3.x 通用主機原理及使用》扯了下3.x中的通用主機，剛好有哥們寫了篇《.NET Core 3.1和WorkerServices構建Windows服務》可以當做通用主機的案例來看。本篇主要聊下asp.net core 3.x中是如何使用通用主機來承載asp ...

一、前言

上一篇《asp.net core 3.x 通用主機原理及使用》扯了下3.x中的通用主機，剛好有哥們寫了篇《.NET Core 3.1和WorkerServices構建Windows服務》可以當做通用主機的案例來看。本篇主要聊下asp.net core 3.x中是如何使用通用主機來承載asp.net core本身的。

註：我是.net framework 4.x跳到.net core 3.x的，基本看源碼總結的，可能某些地方理解不到位，所以此文只作為參考別全信哈。

閱讀前提（參考老A的博客）：

瞭解配置系統和選項模式
瞭解通用主機，可以看看上一篇文章
如果能大概理解Builder模式和上下文模式就更好了

通用主機回顧
通用主機是如何承載asp.net core的
核心類及使用要點
總結

二、回顧通用主機

2.1、IHost表示通用主機

微軟為我們提供了一個預設實現（Microsoft.Extensions.Hosting.Internal.Host），它內部主要包含：ioc容器(服務提供器)、生命周期事件處理器、日誌記錄器、和IHostedService集合以及啟動和停止方法。

2.1.1、ioc服務提供器：

用來存儲各種服務對象，這個根容器是所有IHostedService共用的，各個IHostedService也可以創建主機的“範圍IOC容器”。ioc容器包含微軟為我們塞進去的，和我們自己塞進去的各種服務組件。在主機配置階段微軟會塞入：

HostingEnvironment 主機環境，
- EnvironmentName主機環境(是開發模式？還是生產模式？)
- ApplicationName應用名稱
- ContentRootPath主機的內容根路徑
- ContentRootFileProvider內容提供器

HostBuilderContext 主機創建過程中的上下文對象，在配置主機的多個步驟中傳遞數據。主要包含：HostingEnvironment和AppConfiguration應用配置對象
AppConfiguration 應用配置對象，裡面也包含主機配置對象
IHostLifetime主機生命周期事件處理器
IHostApplicationLifetime 應用生命周期事件處理器
Internal.Host 作為預設主機

所以將來我們定義的類隨時可以註入這些對象，這些對象是在HostBuilder中賦值的，請往下看

2.1.2、生命周期事件處理器

將來主機啟動/停止時會觸發回調相應的幾個方法，比如：主機啟動了應用啟動了應用停止了，主機停止了。我們可以自定義一個事件處理器加入到ioc容器中來實現生命周期事件的訂閱。

2.1.3、IHostedService集合

一個IHostedService的實現類就是一個應用。asp.net core本身就是一個應用。

2.1.4、啟動流程

觸發相應的生命周期事件、遍歷啟動所有IHostedService

2.2、HostBuilder表示主機構造器

它負責主機的配置和生成。它定義了幾個委托集合，並提供相應的方法允許我們的代碼向集合中加入自己的委托，這些委托主要是用來：

向ioc容器註冊服務；
設置主機和應用配置對象的數據源；
配置容器本身（比如替換成別的依賴註入框架）；

將來在調用Build生成最終的主機時會：

創建主機配置生成器ConfigurationBuilder，然後回調我們的代碼提供的委托對配置對象的數據源進行設置，最終通過配置對象生成器.Build生成配置對象
創建HostingEnvironment（含義上面有說），預設用配置對象進行賦值，然後回調我們的代碼提供的委托進一步設置主機環境對象
初始化BuilderContext（含義上面有說）
初始化應用配置生成器，套路給主機配置一樣
初始化IOC容器，
- 先把上面說的對象丟入容器中，
- 註冊預設主機， Internal.Host
- 註冊選項模式需要的幾個服務，
- 註冊日誌系統需要的服務
- 然後回調我們的委托，我們的委托可以註入各種主機需要的服務
- 配置ioc容器本身，我們對微軟提供的ioc進行配置，或乾脆替換為第三方依賴註入框架
嘴周從容器中解析得到主機

2.3、Host.CreateDefaultBuilder進一步簡化主機的配置和創建

創建HostBuilder
設置內容根為當前應用程式根目錄
將以"DOTNET_"的環境變數和命令行參數（如果有）作為“主機配置”的數據源
以以下數據作為“應用配置”的數據源
- json文件appsettings.json和appsettings.{env.EnvironmentName}.json
- 如果是開發模式，則添加一個特殊的json文件作為數據源，這個文件存儲如：賬號密碼資料庫連接字元串等比較機密的信息（文件查找路徑有點複雜，後期補充）
- 添加環境變數作為配置源（沒細看，也許是整個系統的環境變數）
- 嘗試添加命令行參數配置源
添加日誌記錄系統需要的服務以及相關的配置
使用預設的ServiceProvider，當是開發模式時：在創建對象階段開啟依賴註入範圍驗證

以上為通用主機的大致內容，先有個印象，將來需要擴展時在研究源碼

三、通用主機是如何承載asp.net core的

asp.net core 3.x開始直接使用通用主機，主要思路是對通用主機做跟web相關配置（添加跟web相關的配置源和註冊服務），關鍵是會將GenericWebHostService註冊到ioc容器中。對於通用主機來說所謂的應用就是一個實現了IHostedService的類。GenericWebHostService就是這樣一個類，它就基本代表了asp.net core。對於通用主機來說asp.net core不過是一個應用而已。將來通用主機啟動時自然是啟動GenericWebHostService

註：GenericWebHostService會在啟動時創建ApplicationBuilder，然後對其進行配置（中間件管道），然後生成一個Application，最後拿到配置好的IServer（如KestrlServer）然後傳入Application並啟動它，Server開始監聽http請求，後續請求抵達時由Application對象負責將請求傳入中間件管道*（大致這麼個流程，還沒詳細去看GenericWebHostService源碼）

先來看個圖：

核心任務是：

創建GenericWebHostBuilder，它是對通用主機構建器HostBuilder的一個包裝，提供跟web相關的配置源的設置和服務的註冊。構造函數中會做些初始化，預設配置
通過靜態方法Host.ConfigureWebDefaults對GenericWebHostBuilder做進一步的預設配置
調用用戶代碼(我們自己寫的)對GenericWebHostBuilder做進一步配置

所以文章後面部分我們將這個用來承載asp.net core的通用主機稱為“Web主機”，把通用主機配置器HostBuilder的包裝類GenericWebHostBuilder稱為“Web主機配置器”

四、GenericWebHostBuilder

它包裝了HostBuilder，所以可以把它理解為一個特殊的HostBuilder，特殊在它提供web相關的配置api，本質上還是向通用主機配置對象HostBuilder添加各種服務和配置源

4.1、GetSetting、UseSetting

GenericWebHostBuilder有個IConfiguration類型的屬性，可以把它理解為跟web相關的配置對象，它會作為通用主機的配置源，由於通用主機的配置源又是應用配置的數據源，因此最後：應用配置對象 = 通用主機配置對象 + （web主機配置對象）GenericWebHostBuilder._config + 應用配置對象;
_config在構造函數中被初始化，唯一數據源是以"ASPNETCORE_"為首碼的環境變數
另外配置對象還在ExecuteHostingStartups被使用到，後面會詳細講
GetSetting、UseSetting這倆方法分別從_config讀取和寫入配置，所以我們可以在配置主機時更方便的向配置中加入一些值，也可以替換一些值來影響一些組件的配置

所以我們可以在配置web主機時通過UseSetting來快速設置/替換某些配置值，也可以在任意能獲得GenericWebHostBuilder的地方調用GetSetting方便的獲取配置值

4.2、IWebHostEnvironment、WebHostOptions、WebHostBuilderContext

在web主機配置過程中的多個步驟中經常會使用到這幾個對象，我們對web主機進行配置時，提供的委托的參數也經常會攜帶者節參數，因此看看這幾個東西是啥。

IWebHostEnvironment
web主機環境相關，它還繼承IHostEnvironment，所以它包含以下內容：

EnvironmentName 主機運行環境，是開發？生產？
ApplicationName 應用名
ContentRootPath 內容根，預設是應用程式所在目錄
ContentRootFileProvider 內容根對應的文件提供器
WebRootPath web根，預設wwwroot，
WebRootFileProvider web根對應的文件提供器

WebHostOptions
web主機選項對象，雖然是這個名字，但是並沒有應用選項模式，且它是internal修飾的，因此我們寫代碼通常不會訪問到它，但是它在GenericWebHostBuilder有些作用的
它內部包含根web相關的配置：

ApplicationName：應用程式名
PreventHostingStartup、HostingStartupAssemblies、HostingStartupExcludeAssemblies：插件/模塊相關屬性，參考《asp.net core 3.x 模塊化開發之HostingStartup》
Environment：應用程式當前運行，是開發模式？是生產環境？
StartupAssembly：啟動類Startup所在程式集
WebRoot：web靜態資源目錄，通常對應那個wwwroot目錄
ContentRootPath：內容根路徑，通常對應應用程式所在目錄，

WebHostBuilderContext
= IWebHostEnvironment + IConfiguration

private WebHostBuilderContext GetWebHostBuilderContext(HostBuilderContext context)
GenericWebHostBuilder通過這個方法來創建WebHostBuilderContext，web主機配置器內部多個方法都會調用此方法。此方法執行過程大致步驟如下：

使用主機配置器上下文的配置對象來創建一個WebHostOptions，所以WebHostOptions上面那些屬性都是通過配置來賦值的，由於HostBuilderContext的配置對象現在=主機配置對象 + 應用配置對象 + web主機配置對象，可想而知，我們可以通過多種途徑來配置WebHostOptions的屬性
創建WebHostBuilderContext
- Configuration = context.Configuration,
- HostingEnvironment = new HostingEnvironment()
通過HostingEnvironmentExtensions.Initialize對WebHostBuilderContext.HostingEnvironment進行初始化，其實就是將WebHostOptions中相應的屬性賦值上去
最後HostBuilderContext和WebHostOptions被存儲到HostBuilderContext.Properties緩存起來

所以我們平時可以通過多種途徑來配置內容根、web根、應用名、運行環境（開發？生成？）
也可以在配置web主機時的委托中來通過WebHostBuilderContext來訪問到這些屬性和對應的文件提供器
由於IHostingEnvironment會以單例註冊到容器，因此我們將來可以直接註入HostingEnvironment或者web主機環境對象

4.3、public IWebHostBuilder Configure(Action<WebHostBuilderContext, IApplicationBuilder> configure)

調用此方法傳入一個委托，這個委托主要用來配置中間件管道，將來通用主機在啟動時會啟動代表asp.net core的GenericWebHostService，這時我們這個委托就會被調用。所以配置管道的代碼是在HostBuilder.Build().Run()這個Run階段執行，並不是在Build這步

這個方法跟UseStartup（下麵會說）是衝突的，意思只能用其中一個，

要瞭解這個方法的原理，得先說說GenericWebHostServiceOptions，它是一個選項對象，看定義：

 1 namespace Microsoft.AspNetCore.Hosting{
 3     internal class GenericWebHostServiceOptions{
 5        public Action<IApplicationBuilder> ConfigureApplication { get; set; }
 6        public WebHostOptions WebHostOptions { get; set; }
 8        public AggregateException HostingStartupExceptions { get; set; }
10     }
11 }

此對象應用了選項模式，（第5行）ConfigureApplication其實就代表了那個用來配置中間件管道的委托

 1 public IWebHostBuilder Configure(Action<WebHostBuilderContext, IApplicationBuilder> configure){
 2             _builder.ConfigureServices((context, services) => {
 3                 services.Configure<GenericWebHostServiceOptions>(options => {
 4                     var webhostBuilderContext = GetWebHostBuilderContext(context);
 5                     options.ConfigureApplication = app => configure(webhostBuilderContext, app);
 6                 });
 7             });
 8 
 9             return this;
10         }

所以無論是Startup中的Configre方法，還是這裡傳入的委托，最終都會以一個委托的形式賦值到GenericWebHostServiceOptions.ConfigureApplication屬性上，而這個委托將來在主機啟動階段被調用，最終實現允許用戶配置中間件管道的目的

為什麼要提供兩種配置中間件管道的方式呢？因為直接在Program.main里配置更簡單，但是封裝性不好，通過單獨的Startup類更清晰。

所以我們配置中間件管道時除了可以在Startup.Configre中配置，也可以直接在Program.main里配置主機時通過GenericWebHostBuilder.Configure進行配置

未完待續....

asp.net core 3.x 通用主機是如何承載asp.net core的-上