深刻探究ASP.NET Core Startup初始化

時間 2020-11-25

標籤 git github web 編程 app less ide 函數 this 欄目 ASP 简体版

原文原文鏈接

前言

Startup類相信你們都比較熟悉,在咱們使用ASP.NET Core開發過程當中常常用到的類，咱們一般使用它進行IOC服務註冊，配置中間件信息等。雖然它不是必須的，可是將這些操做統一在Startup中作處理，會在實際開發中帶來許多方便。當咱們談起Startup類的時候你有沒有好奇過如下幾點git

爲什麼咱們自定義的Startup能夠正常工做。
咱們定義的Startup類中ConfigureServices和Configure只能叫這個名字才能被調用到嗎？
在使用泛型主機(IHostBuilder)時Startup的構造函數，爲什麼只支持注入IWebHostEnvironment、IHostEnvironment、IConfiguration。
ConfigureServices方法爲什麼只能傳遞IServiceCollection實例。
Configure方法的參數爲什麼能夠是全部在IServiceCollection註冊服務實例。
在ASP.NET Core結合Autofac使用的時候爲什麼咱們添加的ConfigureContainer方法會被調用。
帶着以上幾點疑問，咱們將在本篇文章中探索Startup的源碼，來了解Startup初始化過程到底爲咱們作了些什麼。

Startup的另類指定方式

在平常編碼過程當中，咱們一般使用UseStartup的方式來引入Startup類。可是這並非惟一的方式，還有一種方式是在配置節點中指定Startup所在的程序集來自動查找Startup類，這個咱們能夠在GenericWebHostBuilder的構造函數源碼中的找到相關代碼[點擊查看源碼👈]相信熟悉ASP.Net Core啓動流程的同窗對GenericWebHostBuilder這個類都比較瞭解。ConfigureWebHostDefaults方法中其實調用了ConfigureWebHost方法，ConfigureWebHost方法中實例化了GenericWebHostBuilder對象，啓動流程不是我們的重點，因此這裏只是簡單描述一下。直接找到咱們須要的代碼以下所示github

//判斷是否配置了StartupAssembly參數
if (!string.IsNullOrEmpty(webHostOptions.StartupAssembly))
{
    try
    {
        //根據你配置的程序集去查找Startup
        var startupType = StartupLoader.FindStartupType(webHostOptions.StartupAssembly, webhostContext.HostingEnvironment.EnvironmentName);
        UseStartup(startupType, context, services);
    }
    catch (Exception ex) when (webHostOptions.CaptureStartupErrors)
    {
       //此處省略代碼省略
    }
}

這裏咱們能夠看出來，咱們須要配置StartupAssembly對應的程序集，它能夠經過StartupLoader的FindStartupType方法加載程序集中對應的類。咱們還能夠看到它還傳遞了EnvironmentName環境變量，至於它起到了什麼做用，咱們繼續往下看。
首先咱們須要找到webHostOptions.StartupAssembly是如何被初始化的，在WebHostOptions的構造函數中咱們找到了StartupAssembly初始化的地方[點擊查看源碼👈]web

StartupAssembly = configuration[WebHostDefaults.StartupAssemblyKey];

從這裏也能夠看出來它的值來於配置，它的key來自WebHostDefaults.StartupAssemblyKey這個常量值，最後咱們找到了的值爲編程

public static readonly string StartupAssemblyKey = "startupAssembly";

也就是說只要咱們給startupAssembly配置Startup所在的程序集名稱，它就能夠在程序集中查找Startup類進行初始化，以下所示app

public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureHostConfiguration(config=> {
                    List<KeyValuePair<string, string>> keyValuePairs = new List<KeyValuePair<string, string>>();
                    //配置Startup所在的程序集名稱
                    keyValuePairs.Add(new KeyValuePair<string, string>("startupAssembly", "Startup所在的程序集名稱"));
                    config.AddInMemoryCollection(keyValuePairs);
                })
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    //這樣的話這裏就能夠省略了
                    //webBuilder.UseStartup<Startup>();
                });

回到上面的思路，咱們在StartupLoader類中查看FindStartupType方法，來看下它是經過什麼規則來查找Startup的[點擊查看源碼👈]精簡以後的代碼大體以下less

public static Type FindStartupType(string startupAssemblyName, string environmentName)
{
    var assembly = Assembly.Load(new AssemblyName(startupAssemblyName));
    //名稱Startup+環境變量的類好比(StartupDevelopment)
    var startupNameWithEnv = "Startup" + environmentName;
    //名稱爲Startup的類
    var startupNameWithoutEnv = "Startup";

    // 先查找包含名稱Startup+環境變量的相關類，若是找不到則查找名稱爲Startup的類
    var type =
        assembly.GetType(startupNameWithEnv) ??
        assembly.GetType(startupAssemblyName + "." + startupNameWithEnv) ??
        assembly.GetType(startupNameWithoutEnv) ??
        assembly.GetType(startupAssemblyName + "." + startupNameWithoutEnv);

    if (type == null)
    {
        // 若是上述規則找不到，則在程序集定義的全部類中繼續查找
        var definedTypes = assembly.DefinedTypes.ToList();

        var startupType1 = definedTypes.Where(info => info.Name.Equals(startupNameWithEnv, StringComparison.OrdinalIgnoreCase));
        var startupType2 = definedTypes.Where(info => info.Name.Equals(startupNameWithoutEnv, StringComparison.OrdinalIgnoreCase));

        var typeInfo = startupType1.Concat(startupType2).FirstOrDefault();
        if (typeInfo != null)
        {
            type = typeInfo.AsType();
        }
    }
    //最終返回Startup類型
    return type;
}

經過上述代碼咱們能夠看到在經過配置指定程序集時是如何查找指定規則的Startup類的，基本上能夠理解爲先去查找名稱爲Startup+環境變量的類，若是找不到則繼續查找名稱爲Startup的類，最終會返回Startup的類型傳遞給UseStartup方法。其實咱們最常使用的UseStartup ()方法最終也是轉換成UseStartup(typeof(T))的方式，因此最終這兩種方式走到了相同的地方，接下來咱們步入正題，來一塊兒探究一下Starup到底是如何被初始化的。 ide

Startup的構造函數

相信對Startup有所瞭解的同窗們都比較清楚,在使用泛型主機(IHostBuilder)時Startup的構造函數只支持注入IWebHostEnvironment、IHostEnvironment、IConfiguration,這個在微軟官方文檔中https://docs.microsoft.com/en-us/aspnet/core/fundamentals/startup?view=aspnetcore-3.1#the-startup-class也有介紹,若是還有不熟悉這個操做的請先反思一下本身,而後在查閱微軟官方文檔。接下來咱們就從源碼着手，來探究一下它究竟是如何作到的。沿着上述的操做，繼續查看UseStartup裏的代碼找到了以下的實現[點擊查看源碼👈]函數

//建立Startup實例
object instance = ActivatorUtilities.CreateInstance(new HostServiceProvider(webHostBuilderContext), startupType);

這裏的startupType就是咱們傳遞的Startup類型，關於ActivatorUtilities這個類仍是比較實用的，它爲咱們提供了許多幫助咱們實例化對象的方法，在平常編程中若是有須要可使用這個類。上面的ActivatorUtilities的CreateInstance方法的功能就是根據傳遞IServiceProvider類型的對象去實例化指定的類型對象，咱們這裏的類型就是startupType。它的使用場景就是，若是某個類型須要用過有參構造函數去實例化，而構造函數的參數能夠來自於IServiceProvider的實例，那麼使用這個方法就在合適不過了。上面的代碼傳遞的IServiceProvider的實例是HostServiceProvider對象，接下來咱們找到它的實現源碼[點擊查看源碼👈]代碼並很少咱們就所有粘貼出來ui

private class HostServiceProvider : IServiceProvider
{
    private readonly WebHostBuilderContext _context;
    public HostServiceProvider(WebHostBuilderContext context)
    {
        _context = context;
    }

    public object GetService(Type serviceType)
    {
        // 經過這裏咱們就比較清晰的看出，只有知足這幾種狀況下才能返回具體的實例，其餘的都會返回null
        #pragma warning disable CS0618 // Type or member is obsolete
        if (serviceType == typeof(Microsoft.Extensions.Hosting.IHostingEnvironment)
            || serviceType == typeof(Microsoft.AspNetCore.Hosting.IHostingEnvironment)
        #pragma warning restore CS0618 // Type or member is obsolete
            || serviceType == typeof(IWebHostEnvironment)
            || serviceType == typeof(IHostEnvironment)
            )
        {
            return _context.HostingEnvironment;
        }
        if (serviceType == typeof(IConfiguration))
        {
            return _context.Configuration;
        }
        //不知足這幾種狀況的類型都返回null
        return null;
    }
}

經過這個內部私有類咱們就能清晰的看到爲什麼Starup的構造函數只能注入IWebHostEnvironment、IHostEnvironment、IConfiguration相關實例了，HostServiceProvider類實現了IServiceProvider的GetService方法並作了判斷，只有知足這幾種類型才能返回具體的實例注入，其它不知足條件的類型都會返回null。所以在初始化Starup實例的時候，經過構造函數注入的類型也就只能是這幾種了。最終經過這個構造函數初始化了Startup類的實例。this

ConfigureServices的裝載

接下來咱們就來在UseStartup方法裏繼續查看是如何查找並執行ConfigureServices方法的，繼續查看找到以下實現[點擊查看源碼👈]

//傳遞startupType和環境變量參數查找返回ConfigureServicesBuilder
var configureServicesBuilder = StartupLoader.FindConfigureServicesDelegate(startupType, context.HostingEnvironment.EnvironmentName);
//調用Build方法返回ConfigureServices委託
var configureServices = configureServicesBuilder.Build(instance);
//傳遞services對象即IServiceCollection對象調用ConfigureServices方法
configureServices(services);

從上述代碼中咱們能夠了解到查找並執行ConfigureServices方法的具體步驟可分爲三步，首先在startupType類型中根據環境變量名稱查找具體方法返回ConfigureServicesBuilder實例，而後構建ConfigureServicesBuilder實例返回ConfigureServices方法的委託，最後傳遞IServiceCollection對象執行委託方法。接下來咱們就來查看具體實現源碼。
咱們在StartupLoader類中找到了FindConfigureServicesDelegate方法的相關實現[點擊查看源碼👈]

internal static ConfigureServicesBuilder FindConfigureServicesDelegate(Type startupType, string environmentName)
{
    //根據startupType和根據environmentName構建的Configure{0}Services字符串先去查找返回類型爲IServiceProvider的方法
    //找不到在查找返回值爲void類型的方法
    var servicesMethod = FindMethod(startupType, "Configure{0}Services", environmentName, typeof(IServiceProvider), required: false)
        ?? FindMethod(startupType, "Configure{0}Services", environmentName, typeof(void), required: false);
    //根據查找的到的MethodInfo去構建ConfigureServicesBuilder實例
    return new ConfigureServicesBuilder(servicesMethod);
}

經過這裏的源碼咱們能夠看到在startupType類型裏去查找名字爲environmentName構建的Configure{0}Services的方法信息，而後根據查找的方法信息即MethodInfo對象去構建ConfigureServicesBuilder實例。接下里咱們就來查詢FindMethod方法的實現

private static MethodInfo FindMethod(Type startupType, string methodName, string environmentName, Type returnType = null, bool required = true)
{
    //包含環境變量的ConfigureServices方法名稱好比(ConfigureDevelopmentServices)
    var methodNameWithEnv = string.Format(CultureInfo.InvariantCulture, methodName, environmentName);
    //名爲ConfigureServices的方法
    var methodNameWithNoEnv = string.Format(CultureInfo.InvariantCulture, methodName, "");
    //方法是共有的靜態的或非靜態的方法
    var methods = startupType.GetMethods(BindingFlags.Public | BindingFlags.Instance | BindingFlags.Static);
    //查找包含環境變量的ConfigureServices方法名稱
    var selectedMethods = methods.Where(method => method.Name.Equals(methodNameWithEnv, StringComparison.OrdinalIgnoreCase)).ToList();
    if (selectedMethods.Count > 1)
    {
        //找打多個知足規則的方法直接拋出異常
        throw new InvalidOperationException(string.Format("Having multiple overloads of method '{0}' is not supported.", methodNameWithEnv));

    }
    //若是不存在包含環境變量的ConfigureServices的方法好比(ConfigureDevelopmentServices)，則直接查找方法名爲ConfigureServices的方法
    if (selectedMethods.Count == 0)
    {
        selectedMethods = methods.Where(method => method.Name.Equals(methodNameWithNoEnv, StringComparison.OrdinalIgnoreCase)).ToList();
        //若是存在多個則一樣拋出異常
        if (selectedMethods.Count > 1)
        {
            throw new InvalidOperationException(string.Format("Having multiple overloads of method '{0}' is not supported.", methodNameWithNoEnv));
        }
    }

    var methodInfo = selectedMethods.FirstOrDefault();
    //若是沒找到知足規則的方法，而且知足required參數，則拋出未找到方法的異常
    if (methodInfo == null)
    {
        if (required)
        {
            throw new InvalidOperationException(string.Format("A public method named '{0}' or '{1}' could not be found in the '{2}' type.",
                methodNameWithEnv,
                methodNameWithNoEnv,
                startupType.FullName));

        }
        return null;
    }
    //若是找到了名稱一致的方法，可是返回類型和預期的不一致，也拋出異常
    if (returnType != null && methodInfo.ReturnType != returnType)
    {
        if (required)
        {
            throw new InvalidOperationException(string.Format("The '{0}' method in the type '{1}' must have a return type of '{2}'.",
                methodInfo.Name,
                startupType.FullName,
                returnType.Name));
        }
        return null;
    }
    return methodInfo;
}

經過FindMethod方法咱們能夠獲得幾個結論，首先ConfigureServices方法的名稱能夠是包含環境變量的名稱好比(ConfigureDevelopmentServices)，其次方法能夠爲共有的靜態或非靜態方法。FindMethod方法是真正執行查找的邏輯所在，若是找到相關方法則返回MethodInfo。FindMethod查找的方法名稱是經過methodName參數傳遞進來的，咱們標註的註釋代碼都是直接寫死了ConfigureServices方法，只是爲了便於說明理解，但其實FindMethod是通用方法，接下來咱們要講解的內容還會涉及到這個方法，到時候關於這個代碼的邏輯咱們就不會在進行說明了，由於是同一個方法，但願你們能注意到這一點。
經過上面的相關方法，咱們瞭解到了是經過什麼樣的規則去查找到ConfigureServices的方法信息的，咱們也看到了ConfigureServicesBuilder正是經過查找到的MethodInfo去構造實例的，接下來咱們就來查看下ConfigureServicesBuilder的實現源碼[點擊查看源碼👈]

internal class ConfigureServicesBuilder
{
    //構造函數傳遞的configureServices的MethodInfo
    public ConfigureServicesBuilder(MethodInfo configureServices)
    {
        MethodInfo = configureServices;
    }

    public MethodInfo MethodInfo { get; }
    public Func<Func<IServiceCollection, IServiceProvider>, Func<IServiceCollection, IServiceProvider>> StartupServiceFilters { get; set; } = f => f;
    //Build委託
    public Func<IServiceCollection, IServiceProvider> Build(object instance) => services => Invoke(instance, services);
    private IServiceProvider Invoke(object instance, IServiceCollection services)
    {
        //執行StartupServiceFilters委託參數爲Func<IServiceCollection, IServiceProvider>類型的委託方法即Startup
        //返回了Func<IServiceCollection, IServiceProvider>委託，執行這個委託需傳遞services即IServiceCollections實例返回IServiceProvider類型
        return StartupServiceFilters(Startup)(services);
        IServiceProvider Startup(IServiceCollection serviceCollection) => InvokeCore(instance, serviceCollection);
    }

    private IServiceProvider InvokeCore(object instance, IServiceCollection services)
    {
        if (MethodInfo == null)
        {
            return null;
        }
        // 若是ConfigureServices方法包含多個參數或方法參數類型不是IServiceCollection類型則直接拋出異常
        // 也就是說ConfigureServices只能包含一個參數且類型爲IServiceCollection
        var parameters = MethodInfo.GetParameters();
        if (parameters.Length > 1 ||
            parameters.Any(p => p.ParameterType != typeof(IServiceCollection)))
        {
            throw new InvalidOperationException("The ConfigureServices method must either be parameterless or take only one parameter of type IServiceCollection.");
        }
        //找到ConfigureServices方法的參數，並將services即IServiceCollection的實例傳遞給這個參數
        var arguments = new object[MethodInfo.GetParameters().Length];
        if (parameters.Length > 0)
        {
            arguments[0] = services;
        }
        // 執行返回IServiceProvider實例
        return MethodInfo.InvokeWithoutWrappingExceptions(instance, arguments) as IServiceProvider;
    }
}

看完ConfigureServicesBuilder類的實現邏輯，關於經過什麼樣的邏輯查找並執行ConfigureServices方法的邏輯就很是清晰了。首先是查找ConfigureServices方法，即包含環境變量的ConfigureServices方法名稱好比(ConfigureDevelopmentServices)或名爲ConfigureServices的方法，返回的是ConfigureServicesBuilder對象。而後執行ConfigureServicesBuilder的Build方法，這個方法裏包含了執行ConfigureServices的規則，即ConfigureServices只能包含一個參數且類型爲IServiceCollection，而後將當前程序中存在的IServiceCollection實例傳遞給它。

Configure的裝載

咱們常使用Startup的Configure方法去配置中間件，默認生成的Configure方法爲咱們添加了IApplicationBuilder和IWebHostEnvironment實例，可是其實Configure方法不只僅能夠傳遞這兩個參數，它能夠經過參數注入在IServiceCollection中註冊的全部服務，到底是如何實現的呢，接下來咱們繼續探究UseStartup方法查找源碼查看想實現
[點擊查看源碼👈],咱們抽離出來核心實現以下

//和ConfigureServices查找方式相似傳遞Startup實例和環境變量
ConfigureBuilder configureBuilder = StartupLoader.FindConfigureDelegate(startupType, context.HostingEnvironment.EnvironmentName);
services.Configure<GenericWebHostServiceOptions>(options =>
{
    //經過查看GenericWebHostServiceOptions的源碼可知app其實就是IApplicationBuilder實例
    options.ConfigureApplication = app =>
    {
        startupError?.Throw();
        //執行Startup.Configure，instance爲Startup實例
        if (instance != null && configureBuilder != null)
        {  
            //執行Configure方法傳遞Startup實例和IApplicationBuilder實例
            configureBuilder.Build(instance)(app);
        }
    };
});

咱們經過查看GenericWebHostServiceOptions的源碼可知ConfigureApplication屬性的類型爲Action 也就是說app參數其實就是IApplicationBuilder接口的實例。經過上面這段代碼能夠看出，主要邏輯就是調用StartupLoader的FindConfigureDelegate方法，而後返回ConfigureBuilder建造類，而後構建出Configure方法並執行。首先咱們來查看FindConfigureDelegate的邏輯實現
[ 點擊查看源碼👈]

internal static ConfigureBuilder FindConfigureDelegate(Type startupType, string environmentName)
{
    //經過startup類型和方法名爲Configure或Configure+環境變量名稱的方法
    var configureMethod = FindMethod(startupType, "Configure{0}", environmentName, typeof(void), required: true);
    //用查找到的方法去初始化ConfigureBuilder
    return new ConfigureBuilder(configureMethod);
}

從這裏咱們能夠看到FindConfigureDelegate方法也是調用的FindMethod方法，只是傳遞的方法名字符串爲Configure或Configure+環境變量，關於FindMethod的方法實現咱們在上面講解ConfigureServices方法的時候已經很是詳細的說過了，這裏就不過多的講解了。總之是經過FindMethod去查找名爲Configure的方法或名爲Configure+環境變量的方法好比ConfigureDevelopment查找規則和ConfigureServices是徹底一致的。可是Configure方法卻能夠經過參數注入註冊到IServiceCollection中的服務，答案咱們一樣要在ConfigureBuilder類中去探尋
[點擊查看源碼👈]

internal class ConfigureBuilder
{
    //構造函數傳遞Configure的MethodInfo
    public ConfigureBuilder(MethodInfo configure)
    {
        MethodInfo = configure;
    }

    public MethodInfo MethodInfo { get; }
    //Build方法返回Action<IApplicationBuilder>委託
    public Action<IApplicationBuilder> Build(object instance) => builder => Invoke(instance, builder);
    //執行邏輯
    private void Invoke(object instance, IApplicationBuilder builder)
    {
        //經過IApplicationBuilder的ApplicationServices獲取IServiceProvider實例建立一個做用域
        using (var scope = builder.ApplicationServices.CreateScope())
        {
            //獲取IServiceProvider實例
            var serviceProvider = scope.ServiceProvider;
            //獲取Configure的全部參數
            var parameterInfos = MethodInfo.GetParameters();
            var parameters = new object[parameterInfos.Length];
            for (var index = 0; index < parameterInfos.Length; index++)
            {
                var parameterInfo = parameterInfos[index];
                //若是方法參數爲IApplicationBuilder類型則直接將傳遞過來的IApplicationBuilder賦值給它
                if (parameterInfo.ParameterType == typeof(IApplicationBuilder))
                {
                    parameters[index] = builder;
                }
                else
                {
                    try
                    {
                        //根據方法的參數類型在serviceProvider中獲取具體實例賦值給對應參數
                        parameters[index] = serviceProvider.GetRequiredService(parameterInfo.ParameterType);
                    }
                    catch (Exception ex)
                    {
                        //若是對應的方法參數名稱，沒在serviceProvider中獲取到則直接拋出異常
                        //變相的說明了Configure方法的參數必須是註冊在IServiceCollection中的
                    }
                }
            }
            MethodInfo.InvokeWithoutWrappingExceptions(instance, parameters);
        }
    }
}

經過ConfigureBuilder類的實現邏輯，能夠清晰的看到爲什麼Configure方法參數能夠注入任何在IServiceCollection中註冊的服務了。接下來咱們總結一下Configure方法的初始化邏輯，首先在Startup中查找方法名爲Configure或Configure+環境變量名稱(好比ConfigureDevelopment)的方法，而後查找IApplicationBuilder類型的參數，若是找到則將程序中的IApplicationBuilder實例傳遞給它。至於爲什麼Configure方法可以經過參數注入任何在IServiceCollection中註冊的服務，則是由於循環Configure中的全部參數而後在IOC容器中獲取對應實例賦值過來，Configure方法的參數必定得是在IServiceCollection註冊過的類型，不然會拋出異常。

ConfigureContainer爲什麼會被調用

若是你在ASP.NET Core 3.1中使用過Autofac那麼你對ConfigureContainer方法必定不陌生，它和ConfigureServices、Configure方法同樣的神奇，在幾乎沒有任何約束的狀況下咱們只須要定義ConfigureContainer方法併爲方法傳遞一個ContainerBuilder參數，那麼這個方法就能順利的被調用了。這一切到底是如何實現的呢，接下來咱們繼續探究源碼，找到了以下的邏輯
[點擊查看源碼👈]

//根據規則查找最終返回ConfigureContainerBuilder實例
var configureContainerBuilder = StartupLoader.FindConfigureContainerDelegate(startupType, context.HostingEnvironment.EnvironmentName);
if (configureContainerBuilder.MethodInfo != null)
{
    //獲取容器類型好比若是是autofac則類型爲ContainerBuilder
    var containerType = configureContainerBuilder.GetContainerType();
    // 存儲configureContainerBuilder實例
    _builder.Properties[typeof(ConfigureContainerBuilder)] = configureContainerBuilder;
    //構建一個Action<HostBuilderContext,containerType>類型的委託
    var actionType = typeof(Action<,>).MakeGenericType(typeof(HostBuilderContext), containerType);

    // 獲取此類型的私有ConfigureContainer方法，而後聲明該方法的泛型爲容器類型，而後建立這個方法的委託
    var configureCallback = GetType().GetMethod(nameof(ConfigureContainer), BindingFlags.NonPublic | BindingFlags.Instance)
                                     .MakeGenericMethod(containerType)
                                     .CreateDelegate(actionType, this);

    // 等同於執行_builder.ConfigureContainer<T>(ConfigureContainer)，其中T爲容器類型。
    //C onfigureContainer表示一個委託,即咱們在Startup中定義的ConfigureContainer委託
    typeof(IHostBuilder).GetMethods().First(m => m.Name == nameof(IHostBuilder.ConfigureContainer))
        .MakeGenericMethod(containerType)
        .InvokeWithoutWrappingExceptions(_builder, new object[] { configureCallback });
}

繼續使用老配方，咱們查看StartupLoader的FindConfigureContainerDelegate方法實現
[點擊查看源碼👈]

internal static ConfigureContainerBuilder FindConfigureContainerDelegate(Type startupType, string environmentName)
{
    //根據startupType和根據environmentName構建的Configure{0}Services字符串先去查找返回類型爲IServiceProvider的方法
    var configureMethod = FindMethod(startupType, "Configure{0}Container", environmentName, typeof(void), required: false);
    //用查找到的方法去初始化ConfigureContainerBuilder
    return new ConfigureContainerBuilder(configureMethod);
}

果真仍是這個配方這個味道，廢話很少說直接查看ConfigureContainerBuilder源碼
[點擊查看源碼👈]

internal class ConfigureContainerBuilder
{
    public ConfigureContainerBuilder(MethodInfo configureContainerMethod)
    {
        MethodInfo = configureContainerMethod;
    }
    public MethodInfo MethodInfo { get; }
    public Func<Action<object>, Action<object>> ConfigureContainerFilters { get; set; } = f => f;
    public Action<object> Build(object instance) => container => Invoke(instance, container);
    //查找容器類型，其實就是ConfigureContainer方法的的惟一參數
    public Type GetContainerType()
    {
        var parameters = MethodInfo.GetParameters();
        //ConfigureContainer方法只能包含一個參數
        if (parameters.Length != 1)
        {
            throw new InvalidOperationException($"The {MethodInfo.Name} method must take only one parameter.");
        }
        return parameters[0].ParameterType;
    }

    private void Invoke(object instance, object container)
    {
        ConfigureContainerFilters(StartupConfigureContainer)(container);
        void StartupConfigureContainer(object containerBuilder) => InvokeCore(instance, containerBuilder);
    }
    
    //根據傳遞的container對象執行ConfigureContainer方法邏輯好比使用autofac時ConfigureContainer(ContainerBuilder)
    private void InvokeCore(object instance, object container)
    {
        if (MethodInfo == null)
        {
            return;
        }
        var arguments = new object[1] { container };
        MethodInfo.InvokeWithoutWrappingExceptions(instance, arguments);
    }
}

果不其然千年老方下來仍是那個味道，和ConfigureServices、Configure方法思路幾乎一致。這裏須要注意的是GetContainerType獲取的容器類型是ConfigureContainer方法的惟一參數即容器類型，若是傳遞多個參數則直接拋出異常。其實Startup的ConfigureContainer方法通過花裏胡哨的一番操做以後，最終仍是轉換成了雷士以下的操做方式,這個咱們在上面代碼中構建actionType的時候就能夠看出，最終經過查找到的容器類型去完成註冊等相關操做，這裏就不過多的講解了

Host.CreateDefaultBuilder(args)
        .ConfigureContainer<ContainerBuilder>((context,container)=> {
            container.RegisterType<PersonService>().As<IPersonService>().InstancePerLifetimeScope();
        });

總結

本篇文章咱們主要是圍繞着Startup是如何被初始化進行講解的，分別講解了Startup是如何被實例化的，爲什麼Startup的構造函數只能傳遞IWebHostEnvironment、IHostEnvironment、IConfiguration類型的參數，以及ConfigureServices、Configure、ConfigureContainer方法是如何查找到並被初始化調用的。其中雖然涉及到的代碼比較多，可是總體思路在閱讀源碼後仍是比較清晰的。因爲筆者文筆有限，可能許多地方描述的不夠清晰，亦或是本人能力有限理解的不夠透徹，不過本人在文章中都標記了源碼所在位置的連接，若是有感興趣的同窗能夠自行點擊鏈接查看源碼。Startup類比較經常使用，若是可以更深層次的瞭解其原理，對咱們實際編程過程當中會有很大的幫助，同時呼籲更多的小夥伴們深刻閱讀了解.NET Core的源碼並分享出來。若有各位有疑問或者有了解的更透徹的，歡迎評論區提問或批評指導。

👇歡迎掃碼關注個人公衆號👇