是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的路径中。这让我想起了大卫惠勒的一句格言:计算机科学中的所有问题都可以通过另一个层次的间接解决。

posted on 2019-11-18 11:49  活着的虫子  阅读(512)  评论(0编辑  收藏  举报

导航