CLR 如何加载 DLL？

Question

我的假设始终是 CLR 在应用程序域启动时加载了它所需的所有 DLL。然而，我写了一个例子，让我对这个假设提出质疑。我启动我的应用程序并检查加载了多少模块。

Process[] ObjModulesList;
ProcessModuleCollection ObjModulesOrig;

//Get all modules inside the process
ObjModulesList = Process.GetProcessesByName("MyProcessName");
// Populate the module collection.
ObjModulesOrig = ObjModulesList[0].Modules;

Console.WriteLine(ObjModulesOrig.Count.ToString());

然后我重复完全相同的代码，但我的计数不同。附加的 DLL 是 C:\WINNT\system32\version.dll。

我真的很困惑为什么计数会不同。

有人可以详细说明 CLR 正在做什么以及它如何加载这些东西，以及它是通过什么逻辑这样做的吗？

Answer 1

以下内容复制自 Don Box 的优秀Essential .Net。 （可在此处获取）
（恕我直言，这是任何专业 .Net 开发人员必备的）

CLR 加载器

CLR 加载器负责加载和初始化程序集、模块、资源和类型。 CLR 加载程序会尽可能少地加载和初始化。与 Win32 加载程序不同，CLR 加载程序不会解析并自动加载从属模块（或程序集）。
相反，只有在实际需要时才按需加载从属部分（与 Visual C++ 6.0 的延迟加载功能一样）。这不仅加快了程序初始化时间，而且减少了正在运行的程序消耗的资源量。
在 CLR 中，加载通常由基于类型的即时 (JIT) 编译器触发。当 JIT 编译器尝试将方法体从 CIL 转换为机器代码时，它需要访问声明类型的类型定义以及类型字段的类型定义。此外，JIT 编译器还需要访问正在 JIT 编译的方法的任何局部变量或参数所使用的类型定义。加载类型意味着加载包含类型定义的程序集和模块。
这种按需加载类型（以及程序集和模块）的策略意味着程序中未使用的部分永远不会进入内存。这还意味着正在运行的应用程序经常会看到随着时间的推移加载新的程序集和模块，因为在执行期间需要这些文件中包含的类型。如果这不是您想要的行为，您有两种选择。一种是简单地声明您想要与加载器显式交互的类型的隐藏静态字段。

加载程序通常会代表您隐式地完成工作。开发人员可以通过程序集加载器显式地与加载器交互。程序集加载器通过 System.Reflection.Assembly 类上的 LoadFrom 静态方法向开发人员公开。此方法接受 CODEBASE 字符串，该字符串可以是文件系统路径，也可以是标识包含程序集清单的模块的统一资源定位符 (URL)。如果找不到指定的文件，加载器将抛出 System.FileNotFoundException 异常。如果可以找到指定的文件，但不是包含程序集清单的 CLR 模块，则加载程序将引发 System.BadImageFormatException 异常。最后，如果 CODEBASE 是使用 file: 以外的方案的 URL，则调用者必须具有 WebPermission 访问权限，否则将引发 System.SecurityException 异常。此外，URL 上使用除 file: 之外的协议的程序集在加载之前会首先下载到下载缓存。

清单 2.2 显示了一个简单的 C# 程序，该程序加载位于 file://C:/usr/bin/xyzzy.dll 的程序集，然后创建名为 AcmeCorp.LOB 的包含类型的实例.客户。在此示例中，调用者提供的只是程序集的物理位置。
当程序以这种方式使用程序集加载器时，CLR 会忽略程序集的四部分名称，包括其版本号。

示例 2. 2. 使用显式代码库加载程序集

using System;
using System.Reflection;
public class Utilities {
  public static Object LoadCustomerType() {
    Assembly a = Assembly.LoadFrom(
                    "file: //C:/usr/bin/xyzzy. dll") ;
    return a.CreateInstance("AcmeCorp.LOB.Customer") ;
  }
}

尽管按位置加载程序集有些有趣，但大多数程序集是使用程序集解析器按名称加载的。程序集解析器使用由四部分组成的程序集名称来确定使用程序集加载器将哪个基础文件加载到内存中。如图2.9所示，这个name-to-location解决该过程考虑了多种因素，包括应用程序所在的目录、版本控制策略和其他配置详细信息（所有这些都将在本章后面讨论）。

程序集解析器通过 System.Reflection.Assembly 类的 Load 方法向开发人员公开。如清单 2.3 所示，此方法接受由四部分组成的程序集名称（作为字符串或作为 AssemblyName 引用），表面上看起来与程序集加载器公开的 LoadFrom 方法类似。这种相似性只是表面的，因为 Load 方法首先使用程序集解析器，通过一系列相当复杂的操作来查找合适的文件。这些操作中的第一个是应用版本策略来准确确定应加载所需程序集的哪个版本。

例 2.3。使用程序集解析器加载程序集

using System;
using System.Reflection;
public class Utilities {
  public static Object LoadCustomerType() {
    Assembly a = Assembly.Load(
      "xyzzy, Version=1. 2. 3.4, " +
      "Culture=neutral, PublicKeyToken=9a33f27632997fcc") ;
    return a.CreateInstance("AcmeCorp.LOB.Customer") ;
  }
}

Answer 2

这有点偏离你的问题，但如果你不想按需加载所有程序集，你可以立即加载所有程序集。像这样的事情应该可以解决问题

foreach (AssemblyName asn in Assembly.GetExecutingAssembly().GetReferencedAssemblies())
{
    var asm = Assembly.Load(fn);
    // I've found get types does a good job of ensuring the types are loaded.
    asm.GetTypes();
}

Answer 3

CLR 根据需要加载程序集。当您执行一个方法时，它会查看它在哪里（哪个模块等），如果未加载，则会加载它。

这是一篇关于 CLR 性能的文章，讨论了加载程序集:

当 CLR 即时 (JIT) 编译 Start 方法时，它需要加载该方法中引用的所有程序集。这意味着异常处理程序中引用的所有程序集都将被加载，即使在应用程序执行的大部分时间可能不需要它们。

这篇文章 适用于 SilverLight，但它确实讨论了 CLR 发生的情况。

Answer 4

只要创建相应的 COM 对象，COM DLL 就会按需加载。对于非 COM dll 也可能发生这种情况。