轉自：
http://blogs.msdn.com/yizhang/archive/2007/11/05/net-mscoree-dll.aspx
現在做.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所提供的各項功能。