try import top loader 需要 自己 托管代碼 pat ima

現在做.NET Framework的開發的朋友應該是越來越多了，但是可能並非人人都對MSCOREE.DLL非常了解。而事實上，毫不誇張地說，MSCOREE.DLL是.NET Framework中最為核心的DLL之一，沒有這個DLL，托管程序根本無法開始執行起來，但是由於這個DLL藏在System32目錄下，根本無人問津，可以說是有點委屈了這位.NET Framework中的幕後英雄。本文主要討論MSCOREE.DLL的幾大作用，以及MSCOREE.DLL的兼容性問題。

MSCOREE是托管程序的入口點 讓我們來做一個小實驗：

首先寫一個最最簡單的Hello World程序，用csc編譯（當然你用VS我也沒意見）：

public class Program { public static void Main(string[] args) { System.Console.WriteLine("Hello World!"); } }

然後，在命令行中鍵入：

C:/Windows/System32> ren mscoree.dll mscoree_.dll

請註意在Vista系統上需提升權限，否則重命名失敗。 之後，運行剛才編譯出來的EXE程序。Windows直接報錯：

然後，再把mscoree.dll名字改回去，再次運行A.EXE，這次正確打印出了Hello World。

那麽為什麽一旦沒有MSCOREE.DLL，就算是最簡單的Hello World也無法運行呢？

有在Windows用C/C++編程的朋友們應該熟悉上面那個出錯對話框的意思，這個對話框通常在程序找不到所需的DLL的時候出現。我們可以通過運行Visual Studio中自帶的Depends.exe來查看A.EXE的對於DLL的依賴關系：

可以看到A.EXE只對一個DLL有依賴關系，也就是MSCOREE.DLL。並且A.EXE只用到了MSCOREE.DLL中的一個函數，即_CorExeMain。而MSCOREE.DLL本身卻輸出了137個函數之多。從這個函數的名字大家可以猜出，這個函數是EXE的一個入口點。為了證實這一點，我們可以用DumpBin看看內容：

Microsoft (R) COFF/PE Dumper Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file a.exe PE signature found File Type: EXECUTABLE IMAGE FILE HEADER VALUES 14C machine (x86) 3 number of sections 46C83E12 time date stamp Sun Aug 19 20:56:50 2007 0 file pointer to symbol table 0 number of symbols E0 size of optional header 10E characteristics Executable Line numbers stripped Symbols stripped 32 bit word machine OPTIONAL HEADER VALUES 10B magic # (PE32) 8.00 linker version 400 size of code 600 size of initialized data 0 size of uninitialized data 23DE entry point (004023DE) 2000 base of code 4000 base of data 400000 image base (00400000 to 00407FFF)

註意這個EXE的入口點的RVA是23DE。 再使用Windbg加載A.EXE，使用lmm (list module match)命令查看A.EXE加載的首地址：

0:000> lmm a start end module name 00de0000 00de8000 a (deferred)

可以看到是0x00de0000，那麽再加上23DE這個RVA值，就是程序的入口點。用u命令反匯編看一下：

0:000> u de23de a+0x23de: 00de23de ff250020de00 jmp dword ptr [a+0x2000 (00de2000)]

可以看到這就是一個簡單的JUMP指令，跳轉到0x00de2000所指向的位置，那麽這個位置是什麽函數呢？我們可以通過dds命令查看：

0:000> dds 2000+de0000 00de2000 5b034e50 mscoree!_CorExeMain

到此事實就非常清楚了，任何托管的EXE程序中的入口點都是一條JMP指令直接跳轉到MSCOREE.DLL的_CorExeMain函數執行。而這個_CorExeMain的地址（也就是00de2000所保存的0x5b034e50）則是由OS Loader填入，因為這個位置正是Import Table的位置。 對於一個托管的DLL而言，情況也非常類似，入口點則是_CorDllMain：

可以想象的到，假如你的系統中沒有安裝.NET Framework，那麽執行托管程序也會立刻同樣的對話框。顯然根據這個信息用戶本身很難推斷出發生了什麽問題。一個可行的方案是Windows總是自帶一個MSCOREE.DLL，這個MSCOREE.DLL如果發現沒有.NET Framework則會給出比較清晰的報錯信息。不過由於從Windows 2003之後（包括Vista）的所有Windows版本都會自帶.Net Framework，那麽這個問題基本上不會出現了。

MSCOREE負責選擇.NET Framework版本

MSCOREE.DLL有個非常特殊的地方，也就是它位於C:/Windows/System32目錄下，換句話說，不管你的系統上面安裝了多少個不同的.NET Framework版本，這個DLL都最多只可能有2份（32位/64位各一份），而在C:/Windows/Microsoft.NET/Framework 或者C:/Windows/Microsoft.NET/Framework64下面，則會有多份不同的.NET Framework同時存在。那麽，這個MSCOREE.DLL又是如何對應不同版本的.NET Framework呢？答案很簡單：MSCOREE.DLL通過註冊表信息確定系統上面安裝的.NET Framework版本號碼，然後根據應用程序本身的所要求的版本來選擇一個合適的.NET Framework版本來執行。真正的工作則是交給實際的某個版本的 .NET的DLL執行，在通常情況下，這個DLL是Work Station版本的CLR，名為MSCORWKS.DLL，而服務器版本的CLR則對應MSCORSVR.DLL

程序可以通過MSCOREE調用CLR的提供的功能或者定制CLR

MSCOREE.DLL導出了大量的函數，那麽這些函數是否公開並且可以調用呢？答案是肯定的。幾乎所有這些函數在MSDN中都可以查到對應的文檔，並且在.NET Framework SDK的Include目錄中有一個對應的mscoree.h，提供了這些函數的Prototype。應用程序通過這些函數，可以訪問CLR提供的各項功能，比如：

函數名	用途
GetCORSystemDirectory	獲得進程中加載的CLR的安裝目錄
GetCORVersion	獲得進程中加載的CLR的版本西nxi
GetFileVersion	獲得指定文件的CLR版本信息
GetRequestedRuntimeInfo	獲得指定版本CLR的相關信息
GetRequestedRuntimeVersion	獲得應用程序運行所需要的CLR版本信息
ClrCreateManagedInstance	創建一個.NET對象並返回指定的接口，使用此函數可以訪問大量的.NET Framework的已有功能
CorBindToRuntime	加載指定版本CLR
CorBindToRuntimeHost	在Host中加載指定版本CLR，Hosting時候使用
CreateDebuggingInterfaceFromVersion	獲得對應版本CLR的ICorDebug接口，用於編寫調試器（比如Visual Studio）
CorLaunchApplication	以指定參數啟動托管程序

除此之外還有很多，這裏只是列了一些比較常用的功能而已。可以看到這些功能都非常有用，特別值得提出的是CorBindToRuntimeHost和CreateDebuggingInterfaceFromVersion。前者提供了對CLR各個方面的定制功能，功能非常強大，有興趣的朋友可以參考MSDN或者Customizing the Common Language Runtime一書。而後者則提供了對托管程序的調試支持，通過ICorDebug接口。

MSCOREE提供對COM支持

非托管代碼可以通過COM直接調用.NET的Assembly中的托管對象。以下面這個對象為例，該對象CLSID為{0029598F-26Fa-46F7-953B-86E2947AB19F}，類型為Microsoft.SqlServer.Replication.ComErrorRecord，線程模型為Both，Assembly名稱為Microsoft.SqlServer.Replication, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91，所需CLR版本為v2.0.50727 (2.0 RTM)。最值得註意的是，入口點為mscoree.dll。

對於COM來說，COM只知道CLSID=0029598F-26Fa-46F7-953B-86E2947AB19F}的COM對象位於MSCOREE.DLL中。而事實上，這個類型位於Microsoft.SqlServer.Replication.dll之中，但是COM並不知道，COM只需要知道從MSCOREE.DLL中可以獲得對應的ClassFactory就可以了，然後COM會通過IClassFactory接口創建這個托管對象的實例，並返回對應的接口。假定一個非托管程序嘗試通過COM創建這樣一個對象，那麽會發生下面這些事情： 1. 程序調用CoCreateInstance通知COM需要創建這樣一個對象，CLSID=0029598F-26Fa-46F7-953B-86E2947AB19F，需要返回IDispatch接口 2. COM調用CoGetClassObject函數查找對應的入口DLL 3. COM找到對應的註冊表，發現對應的DLL為MSCOREE.DLL 4. COM加載MSCOREE.DLL，調用DllGetClassObject函數，傳入CLSID 5. MSCOREE.DLL中的DllGetClassObject函數讀入CLSID，找到對應的註冊表，獲取對象的類型名稱，Assembly名稱，CLR版本等信息 6. DllGetClassObject加載對應版本的CLR 7. DllGetClassObject返回一個臨時Class Factory對象的IClassFactory接口 8. COM調用這個Class Factory對象的IClassFactory::CreateInstance方法 9. 這個Class Factory加載對應的CLR，並創建對象，返回一個對象的CCW (Com Callable Wrapper)，並該CCW的返回指定的IDispatch接口 可以看到，這個情況下起到最關鍵作用的是MSCOREE.DLL所提供的DllGetClassObject函數。

除了對用戶自定義的托管對象提供COM支持之外，MSCOREE.DLL自己也支持少量COM對象，因此MSCOREE.dll支持DllGetClassObject, DllRegisterServer, DllUnregisterServer, DllCanUnloadNow這些COM DLL所需要支持的標準函數。

MSCOREE.DLL的兼容性問題

我們可以考慮一下，假如我們現在有了.NET Framework 1.0，然後安裝了.NET Framework 2.0，那麽MSCOREE.DLL會發生變化嗎。答案是可能會，如果到2.0到1.0發生了改變需要修改MSCOREE.DLL（比如多加了一個函數），那麽肯定要更新MSCOREE.DLL，但是這個MSCOREE.DLL必須完全支持所有.NET Framework 1.0中的MSCOREE.DLL中的函數，否則可以想象所有依賴於這些變化的MSCOREE.DLL中的函數程序都會出錯。因此MSCOREE.DLL必須要做到完全向前兼容。

再考慮卸載的情況，假如這個時候.NET Framework 2.0被卸載，那麽MSCOREE.DLL會被還原成.NET Framework 1.0的嗎？這次答案則是不會。因為2.0的MSCOREE.DLL本身支持.NET Framework 1.0，因此無須替換。這樣最為簡單。

事實上是，CLR Team一般很少改動MSCOREE.DLL，避免出現兼容性問題，因此可以預見，MSCOREE.DLL將會是.NET Framework/CLR中變化最少的DLL。換句話說，這篇文章的內容，在可以預見的未來幾個版本基本上不會過時。OK，對於MSCOREE.DLL的討論到這裏就告一段落，有興趣的朋友可以自己動手寫一些小程序，實際體會一下MSCOREE.DLL所提供的各項功能。

DotNET中的幕後英雄：MSCOREE.DLL