是Mscoreei.dll的正确版本吗？

在安装.NET 4.0或更高版本之后，您可能会注意到.NET进程有点不寻常。下面是用.NET 2.0编译器编译的简单“Hello World”可执行文件的加载模块的部分列表。

开始-结束模块名称

60f00000 61491000 mscorwks C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll

6c650000 6c6b6000 mscoreei C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscoreei.dll

6d420000 6d46a000 MSCOREE C:\Windows\SYSTEM32\MSCOREE.DLL

75a80000 75aca000 KERNELBASE C:\Windows\system32\KERNELBASE.dll

这里有些东西看起来不合适-mscoreei.dll文件是从v4.0.30319文件夹加载的。它在v2.0.50727的主clr dll（mscorwks.dll）旁边做什么？实际上，这是预期的行为。我们称mscoreei.dll为“shim实现”，或者简称为“shim impl”，它是.NET 4.0的新功能。上面列表中的第三个dll以前称为“shim”，现在更准确地称为“shell shim”。两者紧密地结合在一起，完成先前由mscoree单独完成的主要工作——提供加载运行时的接口。一般来说，shell shim现在由薄包装函数组成，每个薄包装函数将其功能委托给shim实现中的相应函数。

为什么要分开？作为.NET redist安装的一部分，我们已经看到大量计算机重新启动，通常是因为需要更新正在使用的文件。使用中最常见的文件是mscoree.dll，每个.NET应用程序都会加载该文件，甚至一些服务（如MSI）也会加载该文件。因此，我们进行了mscoree“拆分”，以避免机器重新启动。通过将shim实现移动到特定于版本的文件中，我们可以部署mscoreei.dll的新版本（例如，作为.NET 5.0安装的一部分，在v5.0.NET文件夹中），而无需接触计算机范围内的mscoree.dll文件。下次运行托管应用程序时，mscoree将动态查找新的mscoreei，并将其每个函数调用延迟到该mscoreei。这样，我们就可以在运行现有托管应用程序的机器上部署新版本的框架，而不需要重新启动。

请注意，mscoree总是使用它能找到的最新mscoreei，但实际加载的运行时是一个完全不同的问题。因此，看到mscoreei的新版本在同一个进程中加载了运行时dll的旧版本并不奇怪。事实上，CLR版本已经使用最新的填充程序运行多年了。如果在同时安装了.NET 1.1和.NET 2.0的计算机上运行.NET 1.1应用程序时检查文件版本，则可以看到我使用的填充程序比运行时更新。

开始-结束模块名称

79000000 79045000 mscoree C:\WINDOWS\system32\mscoree.dll

File version: 2.0.50727.42

791b0000 79412000 mscorwks C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll

File version: 1.1.4322.573

现在的区别是，shim的拆分使shim版本不总是与运行时版本匹配变得更加明显，因为版本号就在shim impl的路径中。这让我想起了大卫惠勒的一句格言：计算机科学中的所有问题都可以通过另一个层次的间接解决。