1.?????
寫在前面
近幾年來，當代的程序員為了跟上當今技術的步伐不得不一次又一次的自我知識的移稙和更新。語言
(C++, Visual Basic 6.0, Java)
、框架
(MFC, ATL, STL)
、架構
(COM, CORBA, EJB)
一個又一個為了實現軟件開發的“銀彈”而粉墨登場。
.NET
則是最新一道風景了。
?
2.?????
認清
.NET
之前的世界
在進入
.NET
討論之前，對現存的一些問題進行思考是很有益的。什么問題？就是促使
.NET
平臺產生的原因！為了讓思想走上正軌，我們還是先上上歷史課，把握自己的根本并且明白過去技術的不足。最后我們也就更容易明白
.NET
平臺是如何填補這些不足。
?
2.1?????
C
和
WIN32 API
的程序人生
一般來說，用
C
語言在
window
家庭操作系統上開發軟件時，是直接和
Window
提供的
API
打交道的。無可否認有無數的程序使用這種經典開發方式被成功開發出來了。當然，很少有人不認為直接使用底層
API
是一件復雜的活。
C
語言的第一個問題是它過于簡單。
C
程序員不得不手動進行內存管理、復雜的指針運算和句法構造。還有，
C
語言是結構化語言，沒
OO
特征。當你把
Win32 API
定義的數以千計的全局函數和數據類型加進來后，
C
語言已經成了一種可怕的語言了，再加上當今還有不少長滿蟲子的程序浮出水面，可怕吧！
?
2.2?????
C++/MFC
的程序人生
C++
對基于
C/API
的軟件開發模式作了一個很大的提升。
C++
從很多方面看可以想像成在
C
的層面上再搭建一層面向對象層次。盡管
C++
提供了
OOP
的三大主柱，依然保留了
C
的“痛”——手動進行內存管理、復雜的指針運算和句法構造。
這個復雜性促使不少
C++
框架出臺。如
MFC
；
MFC
為程序員提供了一組類用以簡化
Win32
程序的開發。
MFC
的主要角色是把一組合理相關的
Win32 API
包裝成類、宏和很多代碼生成工具（叫
wizards
）。事實已經證明，即使有
MFC
和一些輔助的工具，
C++
和
C
的復雜性仍然未成降低多少。
?
2.3?????
VB6
的程序人生
簡單在一定場合還是很值得推崇的。不少程序員（尤其是初學者）從
VB
世界獲得了這種簡單性。
VB6
很流行，原因在于它用最少的功夫實現了，一創建復雜的用戶界面，二包裝代碼庫（如
COM
組件），三是寫數據訪問邏輯。
VB
是如何做到把
Win32 API
進行隱藏的呢？答案是它提供了大量的集成代碼向導、內置數據類型、類和函數。
VB
的最大的不足在于，它不是完全的
OO
語言，它是基于對象的語言。例如，
VB
不允許程序員在類型之間建立“是一個”的關系，也就是繼承！也不內置支持類的參數化構造（不支持嗎？）。還有，
VB
不能開發多進程應用，除非你放棄
VB
的簡單性，回到
Win32API
。
?
2.4?????
Java/J2EE
的程序人生
Java
優點有：它是完全的
OOPL
，沿襲了
C
語法的精簡性。
Java
最大賣點就是它的平臺的獨立性。
Java
作為一種語言，去掉
C++
一部分煩復的語法，作為一個平臺引進“包”的概念降低開發的復雜性。包
packages
是一組不同的預定義的類型的合體。使用這些“包”，
Java
程序員可以使用數據庫接接、消息支持、
Web
用可前端和一個豐富的用戶界面創建
100%
的純
Java
應用，
Java
是一種優雅的語言，唯一不足在于，使用
Java
意思著在開發的周期內從前臺到后臺你都要使用
Java
。（這就是純？）結果是，
Java
不提供與其它語言進行集成，因為有違了
Java
初始目標——單一語言滿足所有需要。但實現上，已經有了數以百萬的代碼放在哪兒，而不必
Java
自己重寫了。可惜
Java
把不是問題變成問題。
純
Java
簡單地說，是不合適用于開發重在圖型上和數字上的應用。唯一的選擇是底層的語言，如
C++
。一個可以確實的事實是，
Java
不善于訪問非
Java
的
API
，也就是說它對跨語言集成支持度有限。
?
2.5?????
COM
的程序人生
COM
組件對象模型是
Microsoft
上一個的應用開發框架。從效果上看，
COM
是一種架構：如果你使用
COM
的一致的規則創建你的類型，那么你也在二進制層次創建了一個可復用的模塊。
COM
二制進組件的美麗之處在于它的語言獨立性，也就說，
C++
程序員創建的
COM
類可以被
VB6
調用。
Delphi
程序員調用由
C
創建的
COM
類等。不過你可能已經注意到了，
COM
的語言獨立性有一些限制。例如：沒有辦法對已有的
COM
類進行繼承（因為
COM
本身是不支持典型的繼承機制的）。因此你不得不用更為煩鎖的“有一個”的方法重用
COM
類型。
COM
二制進組件的第二個美麗之處在于位置的透明性。使用諸如程序標識
AppIDs
、存根
stubs
、代理
proxies
和
COM
的運行時環境（啊！？），程序員可以省掉與底層的
sockets
，
RPC
調用和其它的底層的細節。看看下面的
VB COM
客戶代碼：
' This block of VB6 code can activate a COM class written in
' any COM-aware language, which may be located anywhere
' on the network (including your local machine).
Dim c as MyCOMClass
Set c = New MyCOMClass ' Location resolved using AppID.
c.DoSomeWork
盡管
COM
被認為是一個非常成功的對象模型，但是頭巾的背后過于復雜了（當你是一位
C++
程序員，在數月的
COM
的研究后你就會得到這樣的結果）！像降低
C++
的復雜性類似，為了降低
COM
的復雜性，相關的框架又出來了。如活動模板庫
ATL
。
ATL
提供了一組簡化創建
COM
類型的類、模板和宏。很多其它語言也作出了努力，把大部份
COM
的基礎架構隱藏起來（如
VB
的很多相關技術都是基于
COM
的）。不過，單單是語言是足以隱藏
COM
的所有復雜性的，比如你選擇相對較簡單的
COM
語言
VB6
，你仍然不得不面對脆弱的組件注冊問題和很多與部署有關的問題，比如有名的
DLL
地獄。
?
2.6?????
Windows DNA
的程序人生
互聯網的出現為程序開引入更多的復雜性。近幾年，
Microsoft
已經為它的操作系統家族和產品添加面向
Internet
的功能。很可惜，使用基于
COM
的
Windows DNA
開發
Web
應用仍然比較復雜！
復雜性源自一個很簡單的事實，
Windows DNA
需要很多相關技術和語言：
ASP, HTML, XML, JavaScript, VBScript,
和
COM(+)
，還有數據訪問
API
，如：
ADO
。問題出在，這些技術在語法層面上看是完全不相關的。例如，
Javascipt
的語法像
C
，
VBscript
則像
VB6
。
COM
服務器運行在
COM+
運行時環境時與在被
ASP
頁調用時完全兩個樣兒！結果是一個讓人迷惑的技術的大雜燴。
一個更重的東西，就是每一種語言或每一種技術都使用自己的類型系統。
Javascript
整型數據與
VB6
是不完全一致。
?
3.?????
The .NET Solution
上完歷史課后，我們來看看
.NET Framework
是怎樣的一個完全新的模型來改善我們的生活。下面的
.NET Framework
的精簡后的核心功能特色：
3.1?????
對已有的代碼的完全可操作性
這是一個很好東西。已經的
COM
組件可以和新的
.NET
二進制組件共存。而且平臺激活服務
PInvoke
可以讓你在
.NET
的代碼里調用基于
C
的庫（包括操作系統的
API
）。
3.2?????
完全的語言集成
和
COM
不同，
.NET
支持跨語言繼承、跨語言異常處理和跨語言的調錯。
3.3?????
所有的
.NET
語言共用同一個通用運行時引擎
這個引擎是一組“定義良好”的類型，而每一種
.NET
語言都能“明白”這些類型
3.4?????
一個大型的基類庫
這個庫除了像歷來的庫一樣隱藏了底層的復雜性處，更重要的是這繼所有的
.NET
語言提供了一致的對象模型。
3.5?????
不再需要
COM
組裝
IClassFactory, IUnknown, IDispatch, IDL
代碼，和萬惡之源
VARIANT
數據類型不會再在
.NET
組件中使用了。
3.6?????
一個真正簡單的部署模型
有了
.NET
，二進制組件再也不用注冊到系統注冊表了。還有，現在
.NET
允許同一個
.dll
的不同版本存活在同一臺機器上了。
4.?????
.NET
的基本構造塊
前的“理想”都都有賴于三
C
，
.NET
的基本構造塊
CLR
、
CTS
、
CLS!
.NET
可以簡單地被理解一個新的運行時環境加一個新類庫！
u???????
CLR
語言運行時就是一個環境，它負責定位、加載和管理
.NET
類型，管理底層工作如內存管理、安全檢查等。
u???????
CTS
類型系統則是一項標準，它描述了運行時所支持的類型和編程結構，指定類型間如何交互，也規定
metadata
的格式。
u???????
CLS
語言標準也是一項標準，它定義一個通用類型和編程結構的子集，讓所有的
.NET
語言都要明白，從而可相互交互。
與以前一般類庫，
.NET
基類庫異常巨大，因為包含開發不同應用的方面的類，比如數據訪問、安全控制、
XML
操作和
Web
前端控件等。
5.?????
先瞄了一下程序集
.NET binaries
和
COM server
和非托管
Win32 binaries
相比雖然都是
dll
，內部其實完全不同的。
最大的不同在于
.NET binaries
包含是中間語言代碼和自描述的約定格式
metadata
。
當你用
.NET
編譯器創建一個
.dll
或
.exe
后，該模塊將被劃入這個程序集。這什么意思呢？
IDL
對干
metadata
The problems with COM type information are that it is not guaranteed to be present and the fact that IDL code has no way to document the externally referenced servers that are required for the correct operation of the current COM server. In contrast, .NET metadata is always present and is automatically generated by a given .NET-aware compiler.
COM
類型信息不能被保證可用和
IDL
沒有辦法描述目前的
COM server
所依賴的外部引用。是這樣的嗎？
assembly manifest
程序集清單是描述程序集本身的信息，比如，程序集版本信息、區域信息和引用外部程序集列表等。
?
6.?????
單文件和多文件程序集
很多時候一個程序集是對應于一個
dll
文件的，在這個時候可以說，程序集是那個
dll
二進制文件。不過這不完全確切的。從技術角度講，如果一個程序集是只由單一的
.dll
或
.exe
模塊組成，那么我們說這是一個“單文件程序集”。
單文件程序集是一個自治單一包，這個包包包含所有必須的
CIL
、
metadata
和相關的程序集清單
manifest
。
Multifile assemblies, on the other hand, are composed of numerous .NET binaries, each of which is termed a module. When building a multifile assembly, one of these modules (termed the primary module) must contain the assembly manifest (and possibly CIL instructions and metadata for various types). The other related modules contain a module level manifest, CIL, and type metadata. As you might suspect, the primary module documents the set of required secondary modules within the
assembly manifest.
多文件程序集則有點不同，它由很多個被名之模塊的
.NET
二進制文件（一般是
dll
）組成。當為程序集創建程序集清單
manifest
時，其中一個被定為主模塊的模塊包含了程序集清單（有
CIL
代碼和各不同類型的
metadata
），其它的模塊成員則包含自己模塊級的程序集清單。
把程序集按模塊分為不同文件是為了靈活部署，提高性能。當一個用戶引用一個遠程程序集時時，他只需要下載需的模塊就可以了，不必下載整個程序集。
注意：導入名字空間與導入裝配件的區別
導入名字空間只是為讓編譯器能夠找到相應的類型，并不會自動鏈接相關的裝配件（當然要記得系統要自動鏈接一部分默認的裝配件），使用
@Import
指只是為了使用短名機制，如果類型所屬的裝配件沒被加載，
@Import
于事無補
!
編譯器不能找到類型信息。
?
你或許已經注意到，裝配件和名字空間似乎一樣的東西，但事實上這只是偶然發生的，記住兩者實際上是完全不同的東西，從它們使用不同的指示指令可以看到這一點
由此可見，程序集實際上是一個或多個模塊的邏輯集合，這些模塊可以單一地部署和版本控制。
?
7.?????
程序集的首位成員——中間語言
7.1?????
語言集成
每一種不同
.NET
語言的編譯器都生成一樣的中間代碼，所以各種
.NET
語言可以很好的交互。
7.2?????
平臺無關性
CIL
中間語言是平臺無關的，所以
.NET
框架也是平臺無關的。這一點就像
Java
一樣。不過，有一點不同的是，
.NET
還是語言無關的，跨語言的，程序員可以選擇自己喜歡的
.NET
語言。
7.3?????
一次即時編譯
JIT
.NET
運行時環境會為不同的
CPU
和不同的平臺準備相應的
Jitter
編譯器。例如，如果你為手持設備開發一個應用，那么相應的
Jitter
則運行在低內存環境。相反，如果你在一個大型的服務器上部署你的程序集，則
Jitter
會優化使用在大內存的功能。
?
8.?????
程序集的第二位成員——元數據
metadata
元數據精確地描述了定義在程序集內的每一種類型（類、結構、枚舉等），和類型的每一位成員（屬性、方法、事件等）。這些有關類型的元數據信息是由編譯自動為我們生成的，不必自己動手。元數的完備性至使程序集是一個完全自我描述的，所以不用為程序集進行注冊操作。
格式如下：
TypeDef #2 (02000003)
-------------------------------------------------------
TypDefName: CalculatorExample.Calc (02000003)
Flags : [Public] [AutoLayout] [Class]
[AnsiClass] [BeforeFieldInit] (00100001)
Extends : 01000001 [TypeRef] System.Object
Method #1 (06000003)
-------------------------------------------------------
MethodName: Add (06000003)
Flags : [Public] [HideBySig] [ReuseSlot] (00000086)
RVA : 0x00002090
ImplFlags : [IL] [Managed] (00000000)
CallCnvntn: [DEFAULT]
hasThis
ReturnType: I4
2 Arguments
Argument #1: I4
Argument #2: I4
2 Parameters
(1) ParamToken : (08000001) Name : x flags: [none] (00000000)
(2) ParamToken : (08000002) Name : y flags: [none] (00000000)
元數據被用于
.NET
運行時的方方面面，包括在不同的開發工具里也使用它。例如
VS.NET
的智能感應
IntelliSense
就是在設計時讀取元數據實現智能感應的。可以很確定的是，元數據
metadata
是
remoting
、反射
reflection
、晚挷定、
XML Web service
和對象序列化等
.NET
技術的主骨干。
?
9.?????
程序集的第三位成員——程序集清單
manifest
前面已經說了，程序集清單
manifest
包括描述程序集本身的元數據。這些有，當前程序集所依賴的外部程序集列表、版本號和版權信息等。程序集清單也是由編譯器自動生成的。看下面：
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 2:0:0:0
}
.assembly CSharpCalculator
{
.hash algorithm 0x00008004
.ver 0:0:0:0
}
.module CSharpCalculator.exe
.imagebase 0x00400000
.subsystem 0x00000003
.file alignment 512
.corflags 0x00000001
?
10.
已有代碼庫的組織——程序集與名字空間到類型的區分
我們都知道代碼庫對程序員是很重要的。我們
MFC
、
J2EE
、
ATL
等都類庫，它們是怎么組織呢？他說
MFC
等是對現有的代碼的一組定義良好的集合。（回來再看了，沒有用過）
.NET
基類庫使用名字空間進行組織。
.NET
里的名字空間的定義：名字空間是一組在程序集里相關類型。這里有三個對象，名字空間、程序集和類型。要注意一點，單一的程序集可以包含有任意多個名字空間，而一個名字空間也可以包含有任意多個類型。一個很好的例子就是
.NET
基類庫。
.NET
基類庫被劃份為多個離散的程序集。最主要的程序集是
mscorlib.dll
。
mscorlib.dll
又按不的名字空間劃分很多核心的類型（之所說它是核心是因為這些類型包括了封裝各種不同的常見編程工作的類型和
.NET
語言內建數據類型）
.NET
代碼庫與
MFC
等代碼庫的一最關鍵的不同的是，
MFC
代碼庫是語言相關的，而所有的
.NET
都使用一樣的名字空間，一樣的類型。
作為一個
.NET
程序員，他的主要目標是從這些空間里掏寶，掌握空間里的類型的價值。不過首要的是
System
名字空間。
?
11.
引用外部程序集與
GAC
我需要一個類型，引用一個名字空間，名字空間在哪？在程序集。程序集在哪？在……皮之不存，毛將焉附
!
我們需要的是類型的中間代碼定義（也就是代碼所在的程序集），而不是一個邏輯的名字。當你使用一個非默認的程序集的時候，你還是告訴編譯器你的程序集在哪的。大部分主要的
.NET
框架的程序集都放在一個稱為全局程序集緩存
global assembly cache (GAC)
的目錄里。