深入探究ASP.NET Core Startup初始化问题

ASP.NET Core Startup类的奥秘：初始化过程详解

前言：

在ASP.NET Core的开发旅程中，Startup类无疑是一个核心角色。它在我们进行IOC服务注册、配置中间件信息等方面扮演着重要角色。虽然Startup类并不是必须的，但是将相关操作统一在此类中处理，确实能为我们带来诸多便利。那么，你是否曾对Startup类的工作机制产生过好奇？它为何能正常工作？在泛型主机(IHostBuilder)的环境下，它的构造函数为何有特定的注入对象？今天，让我们一起深入Startup的源码，了解它的初始化过程。

一、Startup的另类指定方式

在日常编码过程中，我们通常使用UseStartup的方式来引入Startup类。但实际上，还有一种更为灵活的方式：在配置节点中指定Startup所在的程序集，让系统自动查找并加载Startup类。这一功能在GenericWebHostBuilder的构造函数源码中得以体现。

GenericWebHostBuilder是ASP.NET Core启动流程中的关键角色。在ConfigureWebHostDefaults方法中，会调用ConfigureWebHost方法，而该方法会实例化GenericWebHostBuilder对象。启动流程的细节我们暂不深入，重点关注如何找到并加载Startup类。

源码中，系统会判断是否已经配置了StartupAssembly参数。如果配置了该参数，系统会根据你指定的程序集去查找Startup类。这个过程是通过StartupLoader的FindStartupType方法实现的。值得注意的是，这个方法还会根据EnvironmentName环境变量来决定加载哪个Startup类。

二、Startup类的初始化过程

当我们了解了如何通过程序集加载Startup类后，接下来要的是Startup类的初始化过程。在ASP.NET Core中，Startup类的初始化涉及到几个关键方法：ConfigureServices、Configure以及可能的ConfigureContainer（当结合Autofac使用时）。

1. ConfigureServices方法：用于注册服务到DI容器。它只能传递IServiceCollection实例，因为我们需要在这个方法中定义服务的生命周期、行为等。

2. Configure方法：用于配置HTTP请求管道。它的参数可以是所有在IServiceCollection中注册的服务实例。

3. ConfigureContainer方法：当结合第三方DI容器（如Autofac）使用时，我们可以添加此方法来进行容器的配置。

那么，为什么这些方法有特定的约束和特性呢？这背后涉及到ASP.NET Core的启动流程和DI容器的设计。为了保持系统的稳定性和可扩展性，框架对这些方法进行了特定的封装和处理。

本文详细了ASP.NET Core的Startup类的初始化问题，包括其另类指定方式和初始化过程。通过深入了解源码，我们明白了Startup类的工作机制以及各方法的约束和特性背后的原因。希望这篇文章能对你有所启发，为你的学习和工作带来帮助。在构建Web应用程序时，我们经常会遇到一个重要的环节，那就是初始化WebHostOptions中的StartupAssembly。这个环节涉及到如何根据配置信息找到并加载Startup类，以启动应用程序。让我们深入理解这个过程。

在WebHostOptions的构造函数中，我们看到了StartupAssembly的初始化过程。它从配置中获取一个值，这个值的键是固定的，即WebHostDefaults.StartupAssemblyKey。这个常量值被定义为"startupAssembly"，意味着我们需要在配置中提供Startup所在的程序集名称。

接下来，这个配置信息被用于查找和加载特定的Startup类。这个过程是在StartupLoader类的FindStartupType方法中实现的。这个方法首先尝试根据特定的规则查找Startup类。这些规则包括：先查找名称为“Startup”加上当前环境名称的类，如果找不到，则查找只包含“Startup”名称的类。这些查找操作是在指定的程序集内进行的。

具体的查找过程是这样的：它尝试在程序集中根据完全限定的名称（包括程序集名和类名）查找类。如果找不到，它会尝试只根据类名进行查找。如果还是找不到，它会检查程序集中定义的所有类型，寻找与Startup相关的类型。这个过程确保了即使类的命名规则有所变化，也能找到正确的Startup类。

一旦找到了合适的Startup类，就可以将其传递给UseStartup方法，以初始化应用程序的启动流程。这个过程是在创建主机构建器时配置的，通过添加ConfigureHostConfiguration和ConfigureWebHostDefaults方法来完成。在这个过程中，我们可以根据需要配置其他的主机选项和Web主机默认设置。

Startup的初始化奥秘：从UseStartup()到星动之源

众所周知，我们常常使用的UseStartup()方法最终会转化为UseStartup(typeof(T))的形式。今天，让我们一同揭开Startup初始化的神秘面纱，步入正题，深入其背后的奥妙。

启动我们的之旅，首先聚焦于Startup的构造函数。对于熟悉Startup的开发者而言，当使用泛型主机（IHostBuilder）时，Startup的构造函数仅支持注入IWebHostEnvironment、IHostEnvironment和IConfiguration。这一操作在微软官方文档中有所介绍。若你还不熟悉这些操作，不妨先自我反思，然后查阅微软官方文档以加深理解。接下来，让我们从源码的角度深入这一过程是如何实现的。

在UseStartup方法内部的实现时，我们发现了一段关键代码：创建一个Startup实例。这个实例是通过ActivatorUtilities.CreateInstance方法创建的。这个类实用且功能强大，提供了许多帮助我们实例化对象的方法。在日常编程中，如果需要实例化一个带有参数的类，并且这些参数来自IServiceProvider的实例，那么使用ActivatorUtilities就恰到好处。

在这段代码中，我们看到了一个关键的IServiceProvider实例——HostServiceProvider对象。让我们深入它的实现源码。代码虽不多，但每一行都蕴含深意。这个内部私有类清晰地展示了为何Startup的构造函数只能注入特定的几种类型实例。HostServiceProvider类实现了IServiceProvider的GetService方法，并进行了严格的判断。只有满足特定类型的条件，才能返回具体的实例进行注入。这些特定类型包括IWebHostEnvironment、IHostEnvironment和IConfiguration。不满足这些条件的其他类型都会返回null。

这一机制的背后，体现了泛型主机和Startup初始化过程的精妙设计。通过HostServiceProvider的实现，确保了只有特定的服务能够被注入到Startup的构造函数中。这种设计不仅保证了系统的稳定性和安全性，还提高了代码的灵活性和可维护性。Startup的初始化过程是一个充满奥秘和魅力的领域，值得我们深入和学习。在启动过程中，创建一个Startup实例，是应用程序生命周期中的关键步骤。这个实例是通过构造函数注入的类型来初始化的，而在这个过程中，有几种特定的类型被注入到Startup类的构造函数中。一旦这个Startup实例被成功初始化，接下来的任务就是配置服务。这个过程涉及到查找并执行ConfigureServices方法。

在UseStartup方法里，这个过程被详细展开。通过StartupLoader类中的FindConfigureServicesDelegate方法查找并获取ConfigureServices方法的委托。这个方法根据传入的startupType和环境变量名称来查找具体的方法，并返回一个ConfigureServicesBuilder实例。这个实例进一步被构建，最终生成一个指向ConfigureServices方法的委托。随后，这个委托被调用，将IServiceCollection对象作为参数传递进去。

深入源码，我们可以看到在StartupLoader类中FindConfigureServicesDelegate方法的具体实现。这个方法首先尝试查找一个返回类型为IServiceProvider的“Configure{环境名称}Services”方法。如果找不到这样的方法，它会尝试查找一个返回类型为void的同名方法。一旦找到合适的方法信息，就根据这个信息构建一个ConfigureServicesBuilder实例。

这个寻找并配置服务的过程非常关键，它为应用程序提供了必要的服务和功能。在初始化Startup实例时，这些服务被注册到依赖注入容器中，随后在整个应用程序的生命周期中被使用。理解这个过程对于开发和维护一个健壮、可扩展的应用程序至关重要。每一个步骤，从初始化Startup实例到配置服务，都在为应用程序的成功运行打下坚实的基础。这个过程不仅体现了编程的严谨性，也体现了编程的艺术性，使得应用程序既实用又易于使用。接下来我们来详细一下FindMethod方法的实现逻辑，感受其中的奥秘。

FindMethod方法是一个静态方法，用于在指定的类型startupType中查找特定的方法。方法的名称可以是包含环境变量的名称，例如ConfigureDevelopmentServices。此方法不仅可以找到共有的静态或非静态方法，还能处理方法的重载情况。

该方法通过字符串格式化生成包含环境变量的方法名称methodNameWithEnv和不包含环境变量的方法名称methodNameWithNoEnv。然后，使用反射获取startupType的所有公有方法，包括实例方法和静态方法。

接下来，通过筛选方法名称与methodNameWithEnv相等的方法，找到可能包含环境变量的ConfigureServices方法。如果找到多个满足规则的方法，则直接抛出异常，因为不支持方法的多个重载。

如果没有找到包含环境变量的方法，则继续查找方法名为ConfigureServices的方法。同样，如果存在多个满足规则的方法，也会抛出异常。

然后，从筛选得到的方法列表中选择第一个方法作为结果。如果没有找到满足规则的方法，并且required参数为true，则抛出未找到方法的异常。

如果找到了名称一致的方法，但其返回类型与预期的不一致，也会抛出异常。

通过FindMethod方法我们可以了解到，ConfigureServices方法的名称具有灵活性，可以是包含环境变量的名称，例如ConfigureDevelopmentServices。该方法还可以处理公有静态或非静态方法的查找，为我们在使用反射时提供了极大的便利。在实际应用中，我们可以根据具体需求和环境配置来调用相应的方法，提高代码的灵活性和可维护性。在编程的世界里，FindMethod方法是一个至关重要的角色，因为它承载了查找的真正逻辑。它的任务是从众多方法中准确找到你所需要的那一个，并返回其核心的元数据——MethodInfo。这个方法的重要性不言而喻，因为它为程序的运行提供了方向。

FindMethod方法的查找指令是通过一个关键参数——methodName来传递的。这个参数就像一把钥匙，能够打开方法的大门。当你输入特定的方法名称时，FindMethod就会开始它的搜索任务，寻找与之匹配的方法。一旦找到，它就会返回那个方法的详细信息，即MethodInfo。

在之前的注释代码中，我们直接在ConfigureServices方法中硬编码了FindMethod的相关内容，这样做主要是为了简化理解，让初学者更容易掌握其基本概念。但实际上，FindMethod是一个通用方法，具有广泛的应用场景和强大的功能。在接下来的讲解中，我们还会涉及到这个方法的使用。

对于同一个方法，我们不会重复解释其逻辑部分。因为我们已经详细解释过FindMethod的工作原理和机制，所以大家只需要在此基础上进行理解和应用就可以了。在这里，希望大家能够注意到这一点，避免混淆和误解。

想象一下，FindMethod就像一位侦探，通过细致的调查和推理，找到你需要的那个方法。它默默地执行着查找的任务，确保程序能够准确地找到并执行对应的方法。在这个信息爆炸的时代，FindMethod方法的出现为我们解决复杂问题提供了强有力的工具。它的重要性不言而喻，因为它确保了程序的正常运行和高效执行。我们应该充分理解并应用这个方法，以便在编程的道路上更加游刃有余。深入ConfigureServicesBuilder类

在软件开发的中，我们遇到了一个神秘的类——ConfigureServicesBuilder。这个类的主要职责是负责查找并执行ConfigureServices方法，它是如何做到的呢？让我们揭开它的面纱，深入了解其背后的实现逻辑。

我们需要了解ConfigureServicesBuilder类的构造函数。它接收一个MethodInfo对象作为参数，这个对象包含了我们要执行的ConfigureServices方法的信息。这个构造函数就像是为即将进行的冒险之旅准备好地图和指南针。

接下来，我们看到ConfigureServicesBuilder类中的两个关键属性：MethodInfo和StartupServiceFilters。MethodInfo保存了我们要执行的方法的信息，而StartupServiceFilters则是一个委托，它负责在应用启动时过滤服务。

然后是Build方法，它接受一个实例对象并返回一个Func委托。这个委托的作用是接收一个IServiceCollection对象并返回一个IServiceProvider对象。这是如何执行的呢？在Invoke方法中，我们看到了StartupServiceFilters委托被调用，并传递了一个Func委托，这个委托在接收到IServiceCollection实例后返回IServiceProvider对象。接着，我们看到了InvokeCore方法的实现，它是实际执行ConfigureServices方法的地方。

如果MethodInfo为空，InvokeCore方法会返回null。如果ConfigureServices方法的参数数量超过1个或者参数类型不是IServiceCollection，它会抛出一个InvalidOperationException异常。这是因为ConfigureServices方法只能有一个参数，且参数类型为IServiceCollection。然后，它会找到ConfigureServices方法的参数，并将IServiceCollection的实例传递给这个参数。通过调用MethodInfo的InvokeWithoutWrappingExceptions方法来执行方法并返回IServiceProvider实例。

ConfigureServicesBuilder类的核心逻辑就是查找并执行ConfigureServices方法。它首先验证方法的参数数量和类型，然后执行方法并返回IServiceProvider实例。这个过程被封装在几个方法中，使得代码既简洁又易于理解。现在，我们对ConfigureServicesBuilder类的实现逻辑有了清晰的了解，对于如何通过它查找并执行ConfigureServices方法也有了明确的认识。介绍Configure方法与Startup类的协作奥秘

在ASP.NET Core应用中，Startup类扮演着至关重要的角色。其中，ConfigureServices和Configure方法更是核心中的核心。今天，让我们一起深入这两个方法的运作机制，以及它们如何与环境变量紧密结合。

当我们谈论ConfigureServices方法时，首先要注意的是其命名规则。除了标准的ConfigureServices外，还可以根据环境的不同，使用如ConfigureDevelopmentServices、ConfigureProductionServices等名称。这些方法的核心任务都是返回一个ConfigureServicesBuilder对象。

这个Builder对象，正是执行配置规则的载体。特别的是，它有一个严格的规则：只能接受一个参数，且该参数的类型必须是IServiceCollection。一旦接收到这个参数，Builder就会将其中的IServiceCollection实例视为当前程序中已存在的服务注册信息，进行后续的配置工作。

再来看Configure方法，通常我们在Startup类中看到的默认实现是接收IApplicationBuilder和IWebHostEnvironment作为参数。但Configure方法的强大之处在于，通过参数注入，它可以访问到在IServiceCollection中注册的所有服务。这一切的背后逻辑是什么呢？我们深入源码来寻找答案。

通过StartupLoader的FindConfigureDelegate方法，我们能够找到对应的ConfigureBuilder建造类。这个建造类是如何构建的呢？答案在于FindMethod方法。这个方法根据特定的命名规则（如“Configure”或“Configure”加上环境变量），在Startup类中找到相应的方法。一旦找到，就用这个方法初始化ConfigureBuilder。

进一步地，当我们使用UseStartup方法时，核心的实现逻辑是这样的：首先抽离出Startup实例和环境变量，然后通过ConfigureBuilder来构建并执行Configure方法。在这个过程中，我们看到了一个熟悉的身影——IApplicationBuilder。它是用来配置中间件的核心接口。而我们的Startup类中的Configure方法正是用来配置这些中间件的。

ConfigureServices和Configure方法在ASP.NET Core应用中起到了至关重要的作用。它们通过特定的命名规则和建造模式，紧密地与环境变量结合，为我们提供了灵活、强大的服务配置和中间件配置机制。当我们深入了解这些方法的背后逻辑时，我们更能体会到ASP.NET Core框架的优雅与强大。深入Configure方法：依赖注入的奥秘

在软件开发的架构设计中，依赖注入（DI）是一种重要的技术，它允许我们更灵活地管理组件间的依赖关系。在ASP.NET Core等框架中，Configure方法就是一个典型的依赖注入应用场景。通过ConfigureBuilder类，我们可以将IServiceCollection中注册的服务注入到Configure方法中。接下来，我们将深入这一过程的实现逻辑。

想象一下，我们有一个名为Configure的方法，或者一系列以Configure为前缀的方法，如ConfigureDevelopment和ConfigureServices等。这些方法通常用于配置应用程序的某些方面。为了确保这些方法能够正常工作，它们可能需要访问在IServiceCollection中注册的各种服务。这时，我们就可以借助ConfigureBuilder类来实现这一需求。

我们需要创建一个ConfigureBuilder实例，并在构造函数中传递要执行的Configure方法的MethodInfo。这个信息对于后续的调用至关重要。

接下来，当我们调用Build方法时，它会返回一个Action委托。这个委托内部封装了Invoke方法的实现逻辑。Invoke方法会创建一个IServiceProvider的作用域，并获取该作用域中的服务实例。然后，它会获取Configure方法的所有参数，并根据参数类型从ServiceProvider中获取相应的实例。如果参数是IApplicationBuilder类型，则直接使用传递进来的builder实例。通过这种方式，我们可以确保Configure方法的参数能够正确注入任何在IServiceCollection中注册的服务。

现在让我们来看看具体的实现细节。在Invoke方法中，我们首先通过IApplicationBuilder的ApplicationServices属性获取IServiceProvider实例。然后，我们获取Configure方法的所有参数，并根据参数类型从ServiceProvider中获取相应的实例。如果某个参数无法在ServiceProvider中找到，我们会捕获异常并抛出，这意味着该参数必须在IServiceCollection中注册。我们使用InvokeWithoutWrappingExceptions方法调用Configure方法并传递所有参数。

通过这个过程，我们可以清晰地看到为何Configure方法的参数可以注入任何在IServiceCollection中注册的服务了。这是因为我们通过依赖注入技术将服务实例注入到方法中，从而简化了组件间的依赖管理。这种机制不仅提高了代码的可测试性和可维护性，还使得应用程序更加灵活和可扩展。接下来，让我们深入Configure方法的初始化逻辑。在Startup过程中，系统会自动查找以“Configure”为名称的方法，或者带有环境变量后缀（如“ConfigureDevelopment”）的方法。它会寻找接受IApplicationBuilder类型参数的方法，并将IApplicationBuilder实例传递给这些方法。至于为何Configure方法能够通过参数注入任何在IServiceCollection中注册的服务，原因在于系统在运行时会对Configure方法中的所有参数进行循环处理，并在IOC容器中获取相应的实例进行赋值。如果尝试将未在IServiceCollection中注册的类型作为参数传递给Configure方法，将会抛出异常。

接下来我们进一步理解一个特殊的方法——ConfigureContainer为何会被调用。如果你在ASP.NET Core 3.1中接触过Autofac，那么你一定对ConfigureContainer方法印象深刻。它的神奇之处在于，在几乎没有任何约束的情况下，我们只需定义ConfigureContainer方法并为它传递一个ContainerBuilder参数，这个方法就会被顺利调用。那么这一切是如何实现的呢？接下来我们将继续深入源码。

源码中首先通过特定的规则查找，最终返回了ConfigureContainerBuilder实例。如果找到对应的MethodInfo，那么就会获取容器类型，比如如果是使用Autofac，那么容器类型就是ContainerBuilder。随后将configureContainerBuilder实例存储起来，并构建一个特定类型的委托。这个委托的类型是Action。接着获取当前类型的私有ConfigureContainer方法，声明该方法的泛型为容器类型，并创建这个方法的委托。最后执行类似_builder.ConfigureContainer(ConfigureContainer)的操作，其中T为容器类型。

当我们谈论ConfigureContainer时，它在Startup中的定义就像一道重要的委托。我们首先需要找到那个在IHostBuilder上的ConfigureContainer方法，并为其注入特定的containerType。这个过程就像是精准匹配一道菜的配方，确保每一个元素都恰到好处。

接下来，我们深入StartupLoader的FindConfigureContainerDelegate方法。这个方法的核心是根据提供的startupType和environmentName，去寻找一个特定的ConfigureContainer方法。这个过程就像是寻找一道菜的烹饪指南，确保我们能够按照正确的步骤来制作。

当我们找到这个方法后，我们用它来初始化ConfigureContainerBuilder。这个类就像一个建筑师，它知道如何根据找到的烹饪指南（方法）来构建我们的容器。它有着严格的规定和逻辑，确保每一步都准确无误。

深入ConfigureContainerBuilder的源码，我们会发现它有着严格的结构和逻辑。它首先检查找到的ConfigureContainer方法是否满足要求（只有一个参数）。如果不满足，它会抛出一个异常，就像是一道菜如果缺少关键的原料，我们无法继续制作。

然后，它会查找这个容器的类型，也就是ConfigureContainer方法的唯一参数。接下来，它会根据这个容器对象执行ConfigureContainer方法的逻辑。例如，当我们使用Autofac时，它会调用ConfigureContainer(ContainerBuilder)。这个过程就像是按照烹饪指南来制作菜品，确保每一步都精确无误。

这个过程就像是一个经典的食谱，虽然经过了时间的沉淀，但其核心精神和步骤依然不变。每一步都需要精确无误，确保最终的结果符合预期。这种熟悉的味道和配方让我们感到安心，知道我们可以按照这些步骤来构建我们的容器。启动流程的深入：理解Startup与Container的配置

============================

当我们Startup的初始化流程时，一系列复杂但极其重要的操作跃然纸上。在.NET Core的世界里，Startup类扮演着举足轻重的角色，它如何被实例化、如何配置服务以及容器，都是我们需要深入了解的内容。今天，让我们一起走进这个神秘的世界，Startup背后的秘密。

让我们关注Host的创建过程。通过`Host.CreateDefaultBuilder(args)`方法，我们构建了一个默认的主机构建器。其中，`.ConfigureContainer`方法是配置容器的重要步骤。这个方法接收一个包含容器配置信息的lambda表达式。在这个表达式中，我们看到了对`container.RegisterType().As().InstancePerLifetimeScope()`的调用，这是注册服务到依赖注入容器的典型操作。通过这个操作，我们可以确保在服务生命周期的相应范围内，每次请求IPersonService时都会创建一个新的PersonService实例。

接下来，我们深入Startup类是如何被实例化的。在.NET Core中，Startup类的构造函数有着严格的参数要求，只能接收IWebHostEnvironment、IHostEnvironment或IConfiguration类型的参数。这是因为这些环境参数包含了应用程序运行时的配置信息，对于初始化Startup类是必不可少的。

当我们谈论Startup的配置方法时，我们指的是`ConfigureServices`、`Configure`以及先前提到的`ConfigureContainer`。这些方法是如何被找到并初始化调用的呢？答案在于.NET Core的启动流程。当应用程序启动时，会寻找并执行这些特定的方法，以完成服务的注册、中间件管道的配置以及容器的配置等操作。虽然涉及到的代码较多，但整体思路在阅读源码后会变得清晰。

值得注意的是，Startup类的使用非常普遍，理解其原理对我们实际编程过程中会有很大的帮助。为此，我鼓励大家深入阅读了解.NET Core的源码并分享出来。如果你在阅读过程中有任何疑问或者有更深入的理解，欢迎在评论区提问或分享你的观点。你的每一个反馈都是我前进的动力。让我们一起在编程的道路上共同进步！

如果你在阅读本文过程中觉得有所收获，不妨点个赞或者分享给你的朋友，让更多的人了解.NET Core的启动流程。如果你有任何建议或意见，也请不吝赐教，让我们一起进步！