轉(zhuǎn)自：
http://blogs.msdn.com/yizhang/archive/2007/11/05/net-mscoree-dll.aspx
現(xiàn)在做.NET Framework的開發(fā)的朋友應(yīng)該是越來越多了，但是可能并非人人都對MSCOREE.DLL非常了解。而事實(shí)上，毫不夸張地說，MSCOREE.DLL是.NET Framework中最為核心的DLL之一，沒有這個DLL，托管程序根本無法開始執(zhí)行起來，但是由于這個DLL藏在System32目錄下，根本無人問津，可以說是有點(diǎn)委屈了這位.NET Framework中的幕后英雄。本文主要討論MSCOREE.DLL的幾大作用，以及討論MSCOREE.DLL的兼容性問題。
MSCOREE是托管程序的入口點(diǎn)
讓我們來做一個小實(shí)驗(yàn)：
首先寫一個最最簡單的Hello World程序，用csc編譯（當(dāng)然你用VS我也沒意見）：
|
public class Program
{
public static void Main(string[] args)
{
System.Console.WriteLine("Hello World!");
}
}
|
然后，在命令行中鍵入：
|
C:\Windows\System32> ren mscoree.dll mscoree_.dll
|
請注意在Vista系統(tǒng)上需提升權(quán)限，否則重命名失敗。
之后，運(yùn)行剛才編譯出來的EXE程序。Windows直接報錯：
然后，再把mscoree.dll名字改回去，再次運(yùn)行A.EXE，這次正確打印出了Hello World。
那么為什么一旦沒有MSCOREE.DLL，就算是最簡單的Hello World也無法運(yùn)行呢？
有在Windows用C/C++編程的朋友們應(yīng)該熟悉上面那個出錯對話框的意思，這個對話框通常在程序找不到所需的DLL的時候出現(xiàn)。我們可以通過運(yùn)行Visual Studio中自帶的Depends.exe來查看A.EXE的對于DLL的依賴關(guān)系：
可以看到A.EXE只對一個DLL有依賴關(guān)系，也就是MSCOREE.DLL。并且A.EXE只用到了MSCOREE.DLL中的一個函數(shù)，即_CorExeMain。而MSCOREE.DLL本身卻輸出了137個函數(shù)之多。從這個函數(shù)的名字大家可以猜出，這個函數(shù)是EXE的一個入口點(diǎn)。為了證實(shí)這一點(diǎn)，我們可以用DumpBin看看內(nèi)容：
|
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的入口點(diǎn)的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值，就是程序的入口點(diǎn)。用u命令反匯編看一下：
|
0:000> u de23de
a+0x23de:
00de23de ff250020de00 jmp dword ptr [a+0x2000 (00de2000)]
|
可以看到這就是一個簡單的JUMP指令，跳轉(zhuǎn)到0x00de2000所指向的位置，那么這個位置是什么函數(shù)呢？我們可以通過dds命令查看：
|
0:000> dds 2000+de0000
00de2000 5b034e50 mscoree!_CorExeMain
|
到此事實(shí)就非常清楚了，任何托管的EXE程序中的入口點(diǎn)都是一條JMP指令直接跳轉(zhuǎn)到MSCOREE.DLL的_CorExeMain函數(shù)執(zhí)行。而這個_CorExeMain的地址（也就是00de2000所保存的0x5b034e50）則是由OS Loader填入，因?yàn)檫@個位置正是Import Table的位置。
對于一個托管的DLL而言，情況也非常類似，入口點(diǎn)則是_CorDllMain：
可以想象的到，假如你的系統(tǒng)中沒有安裝.NET Framework，那么執(zhí)行托管程序也會立刻同樣的對話框。顯然根據(jù)這個信息用戶本身很難推斷出發(fā)生了什么問題。一個可行的方案是Windows總是自帶一個MSCOREE.DLL，這個MSCOREE.DLL如果發(fā)現(xiàn)沒有.NET Framework則會給出比較清晰的報錯信息。不過由于從Windows 2003之后（包括Vista）的所有Windows版本都會自帶.Net Framework，那么這個問題基本上不會出現(xiàn)了。
MSCOREE負(fù)責(zé)選擇.NET Framework版本
MSCOREE.DLL有個非常特殊的地方，也就是它位于C:\Windows\System32目錄下，換句話說，不管你的系統(tǒng)上面安裝了多少個不同的.NET Framework版本，這個DLL都最多只可能有2份（32位/64位各一份），而在C:\Windows\Microsoft.NET\Framework 或者C:\Windows\Microsoft.NET\Framework64下面，則會有多份不同的.NET Framework同時存在。那么，這個MSCOREE.DLL又是如何對應(yīng)不同版本的.NET Framework呢？答案很簡單：MSCOREE.DLL通過注冊表信息確定系統(tǒng)上面安裝的.NET Framework版本號碼，然后根據(jù)應(yīng)用程序本身的所要求的版本來選擇一個合適的.NET Framework版本來執(zhí)行。真正的工作則是交給實(shí)際的 某個版本的 .NET的DLL執(zhí)行，在通常情況下，這個DLL是Work Station版本的CLR，名為MSCORWKS.DLL，而服務(wù)器版本的CLR則對應(yīng)MSCORSVR.DLL
程序可以通過MSCOREE調(diào)用CLR的提供的功能或者定制CLR
MSCOREE.DLL導(dǎo)出了大量的函數(shù)，那么這些函數(shù)是否公開并且可以調(diào)用呢？答案是肯定的。幾乎所有這些函數(shù)在MSDN中都可以查到對應(yīng)的文檔，并且在.NET Framework SDK的Include目錄中有一個對應(yīng)的mscoree.h，提供了這些函數(shù)的Prototype。應(yīng)用程序通過這些函數(shù)，可以訪問CLR提供的各項功能，比如：
|
函數(shù)名
|
用途
|
|
GetCORSystemDirectory
|
獲得進(jìn)程中加載的CLR的安裝目錄
|
|
GetCORVersion
|
獲得進(jìn)程中加載的CLR的版本西nxi
|
|
GetFileVersion
|
獲得指定文件的CLR版本信息
|
|
GetRequestedRuntimeInfo
|
獲得指定版本CLR的相關(guān)信息
|
|
GetRequestedRuntimeVersion
|
獲得應(yīng)用程序運(yùn)行所需要的CLR版本信息
|
|
ClrCreateManagedInstance
|
創(chuàng)建一個.NET對象并返回指定的接口，使用此函數(shù)可以訪問大量的.NET Framework的已有功能
|
|
CorBindToRuntime
|
加載指定版本CLR
|
|
CorBindToRuntimeHost
|
在Host中加載指定版本CLR，Hosting時候使用
|
|
CreateDebuggingInterfaceFromVersion
|
獲得對應(yīng)版本CLR的ICorDebug接口，用于編寫調(diào)試器（比如Visual Studio）
|
|
CorLaunchApplication
|
以指定參數(shù)啟動托管程序
|
除此之外還有很多，這里只是列了一些比較常用的功能而已。可以看到這些功能都非常有用，特別值得提出的是CorBindToRuntimeHost和CreateDebuggingInterfaceFromVersion。前者提供了對CLR各個方面的定制功能，功能非常強(qiáng)大，有興趣的朋友可以參考MSDN或者Customizing the Common Language Runtime一書。而后者則提供了對托管程序的調(diào)試支持，通過ICorDebug接口。
MSCOREE提供對COM支持
非托管代碼可以通過COM直接調(diào)用.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)。最值得注意的是，入口點(diǎn)為mscoree.dll。
對于COM來說，COM只知道CLSID=0029598F-26Fa-46F7-953B-86E2947AB19F}的COM對象位于MSCOREE.DLL中。而事實(shí)上，這個類型位于Microsoft.SqlServer.Replication.dll之中，但是COM并不知道，COM只需要知道從MSCOREE.DLL中可以獲得對應(yīng)的ClassFactory就可以了，然后COM會通過IClassFactory接口創(chuàng)建這個托管對象的實(shí)例，并返回對應(yīng)的接口。假定一個非托管程序嘗試通過COM創(chuàng)建這樣一個對象，那么會發(fā)生下面這些事情：
1. 程序調(diào)用CoCreateInstance通知COM需要創(chuàng)建這樣一個對象，CLSID=0029598F-26Fa-46F7-953B-86E2947AB19F，需要返回IDispatch接口
2. COM調(diào)用CoGetClassObject函數(shù)查找對應(yīng)的入口DLL
3. COM找到對應(yīng)的注冊表，發(fā)現(xiàn)對應(yīng)的DLL為MSCOREE.DLL
4. COM加載MSCOREE.DLL，調(diào)用DllGetClassObject函數(shù)，傳入CLSID
5. MSCOREE.DLL中的DllGetClassObject函數(shù)讀入CLSID，找到對應(yīng)的注冊表，獲取對象的類型名稱，Assembly名稱，CLR版本等信息
6. DllGetClassObject加載對應(yīng)版本的CLR
7. DllGetClassObject返回一個臨時Class Factory對象的IClassFactory接口
8. COM調(diào)用這個Class Factory對象的IClassFactory::CreateInstance方法
9. 這個Class Factory加載對應(yīng)的CLR，并創(chuàng)建對象，返回一個對象的CCW (Com Callable Wrapper)，并該CCW的返回指定的IDispatch接口
可以看到，這個情況下起到最關(guān)鍵作用的是MSCOREE.DLL所提供的DllGetClassObject函數(shù)。
除了對用戶自定義的托管對象提供COM支持之外，MSCOREE.DLL自己也支持少量COM對象，因此MSCOREE.dll支持DllGetClassObject, DllRegisterServer, DllUnregisterServer, DllCanUnloadNow這些COM DLL所需要支持的標(biāo)準(zhǔn)函數(shù)。
MSCOREE.DLL的兼容性問題
我們可以考慮一下，假如我們現(xiàn)在有了.NET Framework 1.0，然后安裝了.NET Framework 2.0，那么MSCOREE.DLL會發(fā)生變化嗎。答案是可能會，如果到2.0到1.0發(fā)生了改變需要修改MSCOREE.DLL（比如多加了一個函數(shù)），那么肯定要更新MSCOREE.DLL，但是這個MSCOREE.DLL必須完全支持所有.NET Framework 1.0中的MSCOREE.DLL中的函數(shù)，否則可以想象所有依賴于這些變化的MSCOREE.DLL中的函數(shù)程序都會出錯。因此MSCOREE.DLL必須要做到完全向前兼容。
再考慮卸載的情況，假如這個時候.NET Framework 2.0被卸載，那么MSCOREE.DLL會被還原成.NET Framework 1.0的嗎？這次答案則是不會。因?yàn)?/span>2.0的MSCOREE.DLL本身支持.NET Framework 1.0，因此無須替換。這樣最為簡單。
事實(shí)上是，CLR Team一般很少改動MSCOREE.DLL，避免出現(xiàn)兼容性問題，因此可以預(yù)見，MSCOREE.DLL將會是.NET Framework/CLR中變化最少的DLL。換句話說，這篇文章的內(nèi)容，在可以預(yù)見的未來幾個版本基本上不會過時。OK，對于MSCOREE.DLL的討論到這里就告一段落，有興趣的朋友可以自己動手寫一些小程序，實(shí)際體會一下MSCOREE.DLL所提供的各項功能。