一、前言

上一篇《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原始碼）

先來看個圖：

 核心任務是：

1. 建立GenericWebHostBuilder，它是對通用主機構建器HostBuilder的一個包裝，提供跟web相關的配置源的設定和服務的註冊。建構函式中會做些初始化，預設配置
2. 通過靜態方法Host.ConfigureWebDefaults對GenericWebHostBuilder做進一步的預設配置
3. 呼叫使用者程式碼(我們自己寫的)對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進行配置

未完待續....

&n