上面那句導致的錯誤catch無法捕獲。運行時候瀏覽器中顯示如下錯誤：
=================================
File or assembly name System, or one of its dependencies, was not found.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.IO.FileNotFoundException: File or assembly name System, or one of its dependencies, was not found.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. 

Assembly Load Trace: The following information can be helpful to determine why the assembly 'System' could not be loaded.

在VS2010 中，你默認建立的 WPF 程序就是.Net Framework 4 Client Profile ，而不是.Net Framework 4。昨天下午到今天早上，我在為 System.Web 無法引用而苦惱的問題，就是它導致的。 

VS2010中，我們在項目的屬性下，可以看到項目有以下多種 Target framework 屬性。

我今天碰到的 Sytem.Web 引用問題如下：

在用 VS2010 Beta2 書寫一個WPF應用的時候，要使用 System.Web.HttpUtility.UrlEncode()方法時，發現竟然無法增加對 System.Web 的引用。如下圖：

.NET Reference 中沒有 System.Web 組件。

使用 Browse 方式打開指定目錄的文件 C:\Windows\Microsoft.NET\Framework\v4.0.21006\System.Web.dll  也不行。

如下圖：

GAC 中也沒有 4.0 版本的 System.Web 組件,如下圖：

強制添加 C:\Windows\Microsoft.NET\Framework\v4.0.21006\System.Web.dll   到GAC 時會報錯誤：

---------------------------
					
Cannot Add Assembly 
---------------------------
					
Unable to add the selected assembly.  The assembly must have a strong name (name, version and public key). 
---------------------------
					
確定   
---------------------------

這個文件的信息如下：

但是VS2010 Beta2 建立的 Web 項目，默認就有 System.Web 的引用，這里沒有任何問題，如下圖：

查看這時候的 System.Web 屬性，如下：

把 C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Web.dll 放入 GAC也會報錯誤：

---------------------------
					
Cannot Add Assembly 
---------------------------
					
Unable to add the selected assembly.  The assembly must have a strong name (name, version and public key). 
---------------------------
					
確定   
---------------------------

日前微軟推出了基于.NET Framework 2.0開發的Petshop 4。新的Petshop4實現了與Petshop 3相同甚至更多的特性，由于采用了Master Pages，Membership，以及Profile，SqlCacheDependency，但是代碼量卻減少了四分之一。同時，在事務、數據緩存、安全方面使用了.NET 2.0附帶的特性，構建了一個靈活的最佳實踐的應用程序。

他們利用了Project Conversion Wizard把項目從ASP.NET 1.1移植到了ASP.NET 2.0，然后做了以下改動：

1．用System.Transactions代替了原來的Serviced Components提供的事務功能

代碼實現：PetShop.BLL.OrderSynchronous 的 public void Insert(PetShop.Model.OrderInfo order)。

2．用強類型的范型集合代替了原來的弱類型集合

        public IList<ProductInfo> GetProductsByCategory(string category)

        {

            // Return new if the string is empty

            if (string.IsNullOrEmpty(category))

                return new List<ProductInfo>();

            // Run a search against the data store

            return dal.GetProductsByCategory(category);

        }

3．采用ASP.NET 2.0 Membership來做認證和授權

4．創建了針對Oracle 10g的Custom  ASP.NET 2.0 Membership Provider

5．利用ASP.NET 2.0的Custom Oracle 和 SQL Server Profile Providers 做用戶狀態管理，包括購物車等

6．采用了Master Pages，取代了原來的用戶控件，來實現統一的界面效果

7．使用了ASP.NET 2.0 Wizard控件實現check-out

8．使用了SqlCacheDependency來實現數據庫層次的緩存更新(cache invalidation)功能

9．使用了消息隊列來實現異時訂單處理。

2.整體架構：

數據庫：(暫略)

項目列表：從整體可以看出，Pet Shop 4的項目體系已經很龐大，考慮的方面也較3.0更全面復雜。

項目分解：

由于整體已經有22個項目，所以，對于初學者一看就暈了，所以，我做了分解，可以大體上分幾塊去理解。

3．Petshop 4中的設計模式：

工廠模式:

首當其沖的就是工廠模式，很容易就可以看出來，也是應用最多的。

DALFactory：數據訪問層的抽象工廠（決定創建哪種數據庫類型的數據訪問層。可以選擇：SQLServer，Oracle）

CacheDependencyFactory：緩存依賴類的工廠類。（創建具體表的緩存依賴）

MessagingFactory ：異時處理消息隊列的抽象工廠（反射創建具體的異時處理類）

ProfileDALFactory：ProfileDAL的工廠類(反射選擇創建Oracle 和SQL Server的 ProfileDAL)

　　中圖分類號:TP311文獻標識碼:A文章編號:1009-3044(2010)17-4660-04

　　Based on .Net Framework's Research and Development about Web Management System (C#)

　　CHEN Zhao-yun, DONG Hai-yan, ZHOU Yong-fu

　　(Heyuan Vocational Technical College of Electronics and Information Engineering, Heyuan 517000, China)

　　Abstract: This composition introduces Users Manager System of Web in details from the system’s environment to the system’s framework and development’s technology.It can helps many programmers to solve the problems about C# programming、using components about .NET framwork、data Acquisition、databinding and so on.

　　Key words: C#; components; data Acquisition; databinding

　　Microsoft.NET Framework是微軟于2000年推出的用于構建新一代Internet集成服務平臺的最新框架,這種集成服務平臺允許各種系統環境下的應用程序通過互聯網進行通信和共享數據。

Java runs on any platform with a Java VM. C# only runs in Windows for the foreseeable future.

.NET and J2EE offer pretty much the same laundry list of features, albeit in different ways.

By allowing cross-language component interactions, .NET is enfranchising Perl, Eiffel, Cobol, and other programmers.

.NET is a good thing for those of you committed to Microsoft architectures.

.NET will undoubtedly become the default development environment for Microsoft platforms.

However, several of the goals of the .NET platform are fairly lofty and not at all guaranteed to fly, at least not in the short term.

It would be easy to dismiss .NET as more Microsoft marketing-ware and continue on your merry way. But don't.

[Microsoft is] fighting Java and open source initiatives on their own terms, putting their own spin on "open" and attempting to directly address the needs of developers.

If you consider yourself an evangelist for Java or open source platforms, then the nature of the war is changing. Be prepared.

Microsoft has put a stake in the ground with SOAP, and they're pushing hard to put something understandable and useful in the hands of developers. J2EE proponents need to do the same with their platform.

Even if you don't write code dedicated to Microsoft platforms, you have probably heard by now about Microsoft .NET, Microsoft's latest volley in their campaign against all things non-Windows. If you've read the media spin from Microsoft, or browsed through the scant technical material available on the MSDN site, or even if you attended the Microsoft Professional Developers' Conference (where the .NET platform was officially "launched"), you're probably still left with at least two big questions:

• What exactly is the .NET platform?
• How does the .NET architecture measure up against J2EE?

　　第一步：下載.NET Mass Downloader.

　　第二步：下載.NET Framework3.5的安裝文件,這是完整的可再發行組件包。有190多MB，下載完成后，安裝它。

　　第三步：找到文件下載的目錄。例如，我把文件放在的C盤的跟目錄，文件的解壓后的目錄為C:\NetMassDownloader，然后我們運行cmd.exe，指向我剛才解壓的目錄：

　　第四步：對NetMassDownloader的參數進行設置，我是這樣設置的。

　　這條命令我解釋一下：

　　(1)-d C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727是我們安裝.net2.0時，.net類庫存放的文件夾。

　　(2)-output E:\NETFramework2.0是我們存放下載的.Net Framework的源代碼的文件夾。這個目錄你可以自定義，不一定非要和我寫的一樣。

　　(3)-vsver 8.0表示我們要下載的源代碼的版本是.net2.0

　　netmassdownloader.exe還有其他一些參數可以設置，大家輸入netmassdownloader.exe /?就可以查看。在此就不羅嗦了。

　　參數配置好后，我們允許它，我們不要關閉它，.net framework的源代碼大概有120多MB，我們耐心等待就行了，在運行的時候，可能會出現一些文件找不到的信息，我們不要管它。

　　第五步：源代碼下載完成后，我們開始配置VS2005。

　　(1)按照我的截圖配置：

　　將啟用“僅我的代碼”(僅限托管)和要求源文件與原版本完全匹配的選項給去掉。

　　第六步：配置你的解決方案，以后如果你創建了新的解決方案，第六步也是少不了的。

　　在“包含源代碼的目錄”中設定E:\NETFramework2.0，就是我們下載的.net framework2.0的源代碼的目錄。

服務器.netframework asp.net2.0每三分鐘報錯|perflib1008。服務器上每三分鐘都會報錯：source Perflib ID:1008，請問這個要如何解決呢？

事件類型: 錯誤
事件來源: Perflib
事件種類: 無
事件 ID: 1008
日期:  2007-9-26
事件:  13:46:46
用戶:  N/A
計算機: REPORTSRV
描述:DLL "C:\WINNT\Microsoft.NET\Framework\v2.0.50727\aspnet_perf.dll" 中服務
"ASP.NET_2.0.50727" 的打開過程出現故障。 該服務的性能數據將不可使用。返回的狀態碼 是數據 DWORD 0。
數據:0000: 05 40 00 80               .@.?

解決辦法：
回答：根據您的描述，我對這個問題的理解是：Windows 2000 Server ，在日志中每隔3分鐘記錄Perflib 1008 的錯誤事件。如果我的理解有誤，請告訴我。

這是由于沒有正確安裝aspnet的性能計數器的dll文件導致，建議您嘗試以下方法修復：
1. 在命令行，輸入以下命令卸載mscoree.dll和aspnet_isapi.dll的注冊信息。
regsvr32 /u %windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
regsvr32 /u %windir%\System32\mscoree.dll
完成后重啟系統。

2. 如果卸載出錯，在命令行，定位到C:\WINNT\Microsoft.NET\Framework\v2.0.50727目錄，運行以下命令：
aspnet_regiis.exe –ua 卸載ASP.NET
aspnet_regiis.exe –I 重新安裝 

完成后，重啟系統，查看是否還有問題。建議您從添加刪除程序刪除所有.net framework，然后重啟系統，重新安裝，看是否還有問題。我意思是重新安裝.net framework，這個計數器是由Framework 提供的，重新安裝該組件，則可以重新創建計數器。

另外，這是ASP.NET的性能計數器無法使用，但不影響ASP.NET的使用，如果不使用性能計數器，您也可以禁用該計數器，更改以下注冊表鍵值：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP.NET_2.0.50727\Performance
"Disable Performance Counters"=dword:00000001

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP.NET\Performance
"Disable Performance Counters"=dword:00000001

【相干文章:Java的中文編程與配置心…】

【擴大閱讀:蔡學鏞：編譯、反編譯、…】

以下便是ado.net新增的特性： 【擴大信息:Web服務器和應用程序服務…】

1. 批量復制操作（bulk copy operation）

將數值從一個數值源批量復制到另一個數值源是ado.net 2.0的一個新特性。批量復制類提供了最快的要領把數值從一個數值源遷徙到另一個數值源。每個ado.net的數值提供者城市提供相應的批量復制類。例如，在sql.net數值提供者里，批量復制操作是由一個叫sqlbulkcopy的類來完成的，它可以讀取一個dataset, datatable, datareader或xml 對象。

2.批量更新（batch update）

要是數值庫服務器支持批量更新特性，batch update代替了幾個短周期提交請求的方式，從而大大改善在一個短周期內向服務器產生多個批量更新時的性能。updatebatchsize屬asp.net 工作流性提供在一批更新里要更新行數。這個屬性值能被限制到小數位。

3.數值分頁

現在command對象具有一個新的執行要領叫做executepagereader。這個要領有三個參數——commandbehavior, startindex, 與 pagesize。要是你意料得到數值行數是101－200，你可以通過挪用這個要領設置startindex為101與pagesize為100而輕易完成這個功能。

4.數值毗連（connection）明細

現在你可以通過設置毗連的statisticsenabled屬性為真來獲取一個毗連更多的信息。connection對象提供了兩個新要領——retrievestatistics 與 resetstatistics。retrievestatistics要領歸回一個hashtable對象來填充毗連信息，如：數值轉移，用戶明細，游標明細，緩存信息與事務處理。

5.dataset.remoringformat屬性

當dataset.remoringformat設置為二進制時， dataset的序列化格式由二進制格式代替了原本的xml標記格式，這種改變能顯著改善序列化與還原序列化操作的性能。

.NET Framework 3.0 中增加了不少新功能，例如 Windows Workflow Foundation (WF)、Windows Communication Foundation (WCF)、Windows Presentation Foundation (WPF) 和 Windows CardSpace，.NET Framework 3.5 在這些新增功能的基礎上增量構建而成。這個之外，.NET Framework 3.5 還包羅若干技術領域中的大量新功能，它們以新程序集的形式添加，以制止重大更改。這asp.net 工作流些新功能包孕：

與語言集成查詢 (LINQ) 和數值感知緊密集成。借助這個新功能，您可以使用相同的語法，在任何支持 LINQ 的語言中編著相干代碼，以篩選和枚舉多種類型的 SQL 數值、調集、XML 和數值集，以及創建它們的投影。
利用 ASP.NET AJAX 可以創建更有效、更具交互性、高度個性化的 Web 體驗，這些體驗在所有最流行的瀏覽器上都能實現。
用于生成 WCF 服務的全新 Web 協議支持，包孕 AJAX、JSON、REST、POX、RSS、ATOM 和若干新的 WS-* 標準。
Visual Studio 2008 中面向 WF、WCF 和 WPF 的完整工具支持，其中包孕支持工作流的服務這一新技術。
.NET Framework 3.5 基類庫 (BCL) 中的新類可滿足許多常見的客戶請求。

重要事項：
要是安裝有 .NET Framework 3.5 的早期預發行版本，則運行此安裝之前，必須使用“添加/刪除程序”卸載那一些預發行版本。

.NET Framework 3.5 SP1集成了此前發布的三十個相關Hotfix熱修復補丁，同時還引入了不少新特性和改進：

1、ASP.NET動態數據，它提供了豐富的框架，從而使用戶可以快速進行數據驅動的開發，而無需編寫代碼；ASP.NET AJA 的一項新增功能，對管理瀏覽器歷史記錄提供了支持（支持后退按鈕）。有關更多信息，請參見ASP.NET和Web開發中的新增功能。

2、對公共語言運行時的核心改進包括：改進了.NET Framework本機映像的布局、選擇不再對完全受信任的程序集進行強名稱驗證、提高了應用程序啟動性能、改進了生成的代碼以縮短端對端應用程序執行時間、選擇在ASLR（地址空間布局隨機化）模式下運行托管代碼（如果操作系統支持）。此外，從網絡共享打開的托管應用程序在完全受信任環境下運行時與本機應用程序具有相同的行為。

3、提高了Windows Presentation Foundation的性能，包括縮短了啟動時間，提高了與位圖效果有關的性能。WPF的其他新增功能包括：改善了對業務線應用程序、本機初始屏幕、DirectX 像素著色器的支持，并且新增了WebBrowser控件。

4、ClickOnce應用程序發行者可以決定在適當情況下不進行簽名和加密，開發人員可以編程方式安裝ClickOnce應用程序以顯示自定義署名，并且ClickOnce錯誤對話框支持鏈接到Web上應用程序特定的支持網站。

5、實體框架是從現有的一套ADO.NET數據訪問技術發展而來的。利用實體框架，開發人員可以按照應用程序特定的域模型（而不是基礎數據庫模型）來針對關系數據庫進行編程。有關更多信息，請參見實體框架入門。實體框架還引入了一些其他功能，包括支持SQL Server 2008的新類型、默認實體圖形序列化和實體數據源。在此版本中，實體框架支持SQL Server 2008中的新日期和文件流功能。圖形序列化工作可幫助開發人員生成將全部圖形建模為數據協定的Windows Communication Foundation (WCF)服務。實體數據源為希望使用實體框架的ASP.NET應用程序構建者提供了傳統的數據源體驗。

6、LINQ to SQL新增了對SQL Server 2008中的新日期和文件流功能的支持。

7、ADO.NET Data Services Framework由滿足以下條件的模式和庫組合而成：支持將數據公開為一項基于REST（具象狀態傳輸）的靈活數據服務，企業網絡內部或整個互聯網上的Web客戶端都可以使用該服務。ADO.NET Data Services Framework支持基于任何數據源創建數據服務。通過與 ADO.NET Entity Framework 的充分集成，可以輕松公開基礎存儲架構的概念視圖模型。可以輕松地從任一平臺訪問使用ADO.NET Data Services Framework創建的服務以及兼容的Windows Live (dev.live.com)服務。針對運行在微軟平臺上的客戶端應用程序提供了一組客戶端庫，以簡化與數據服務的交互。例如，基于.NET Framework的客戶端可以使用LINQ查詢數據服務，也可以使用簡單的.NET Framework對象層更新此服務中的數據。

8、現在，Windows Communication Foundation改進了對互操作性的支持，增強了部分受信任情況下的調試體驗，并且擴展了整合協議支持以便在Web 2.0應用程序中可以進行更廣泛的應用，從而使DataContract序列化程序變得更易于使用。

9、用于SQL Server(SqlClient) 的.NET Framework數據提供程序新增了對SQL Server 2008中的文件流和稀疏列功能的支持

.NET Framework 3.5 SP1正式版完整安裝包本地下載(231MB)：
http://drivers.mydrivers.com/drivers/243-97382-Microsoft-Microsoft.NET-Framework-3.5-SP1/

知識庫文章KB951847：
http://support.microsoft.com/kb/951847/en-us

發行說明：
http://download.microsoft.com/download/A/2/8/A2807F78-C861-4B66-9B31-9205C3F22252/dotNet35SP1Readme.htm

　　c:\windows\system32\mscoree.dll

　　c:\windows\system32\mscorier.dll

　　c:\windows\system32\mscories.dll

　　c:\windows\system32\dfshim.dll

　　c:\windows\system32\netfxperf.dll

　　這幾個文件一定要放在system32下面

　　C:\windows\system32\mui\0409\mscoreer.dll

　　C:\windows\system32\mui\0409\mscorees.dll

　　我們猜想mui下面其他們版本的也是必須的

　　C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089

　　c:\windows\assembly\gac_32\[others]

　　需要其他們的組件也要添加,,比如System.Windows.Forms

　　C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorjit.dll

　　C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll

　　C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\[others]

　　這個文件夾下面只需要mscorjit.dll mscorwks.dll兩個文件就可以使console運作正常。

　　c:\windows\winsxs\Manifests\...

　　c:\windows\winsxs\policies\...

　　c:\windows\winsxs\...

　　winsxs下有很多重要的組件,版本也很繁雜。確保一個都不能少。這些文件支撐著mscorwks.dll,沒有他們,mscorwks也無法加載。

　　REG:

　　HKEY_CLASSES_ROOT\TypeLib\{BED7F4EA-1A96-11D2-8F08-00A0C9A6186D}

　　HKEY_CLASSES_ROOT\TypeLib\{BED7F4EA-1A96-11D2-8F08-00A0C9A6186D}\2.0 = REG_SZ, mscorlib.dll

　　HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\InstallRoot = REG_SZ,C:\WINDOWS\Microsoft.NET\Framework\

　　只要設置了安裝位置,jit自己能找到相應的framework。有了這些文件,你們就能運行.net 2.0的程序了。

我們來看看以下 ClrInfo.cs 吧：

using System; 
using System.Text; 

namespace Skyiv 
{ 
  public class ClrInfo 
  { 
    static void Main() 
    { 
      Console.WriteLine("      OS Version: {0}", Environment.OSVersion); 
      Console.WriteLine("     CLR Version: {0}  ( {1} )", Environment.Version, RuntimeFramework.CurrentFramework); 
      Console.WriteLine("Default Encoding: {0}", Encoding.Default); 
      Console.WriteLine(); 
      Console.WriteLine(typeof(string).AssemblyQualifiedName); 
#if !NetFx20 
      Console.WriteLine(typeof(System.IO.Packaging.Package).AssemblyQualifiedName); 
      Console.WriteLine(typeof(System.TimeZoneInfo).AssemblyQualifiedName); 
#endif 
      Console.WriteLine(); 
      Console.WriteLine("Available Frameworks:"); 
      foreach (var frame in RuntimeFramework.AvailableFrameworks) Console.WriteLine("  " + frame); 
    } 
  } 
}

使用以下 makefile 文件來編譯(請參見: 淺談 make 工具)：

CLR35 = C:\Windows\Microsoft.NET\Framework\v3.5
CLR40 = C:\Windows\Microsoft.NET\Framework\v4.0.30319
CSC35 = $(CLR35)\csc.exe
CSC40 = $(CLR40)\csc.exe
SRC1 = ClrInfo.cs RuntimeFramework.cs

ClrInfo20.exe: $(SRC1)
	$(CSC35) -out:$@ $(SRC1) -D:NetFx20

ClrInfo35.exe: $(SRC1)
	$(CSC35) -out:$@ $(SRC1) -r:WindowsBase.dll

ClrInfo40.exe: $(SRC1)
	$(CSC40) -out:$@ $(SRC1) -r:$(CLR40)\WPF\WindowsBase.dll

 　　使用 nmake.exe 進行編譯(所需的 RuntimeFamework.cs 請參見 .NET Framework CLR 版本檢測)：

E:\CS\ClrInfo> nmake ClrInfo20.exe
Microsoft (R) 程序維護實用工具 9.00.30729.01 版
版權所有(C) Microsoft Corporation。保留所有權利。

C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe -out:ClrInfo20.exe ClrInfo.cs RuntimeFramework.cs -D:NetFx20
適用于 Microsoft(R) .NET Framework 3.5 版的 Microsoft(R) Visual C# 2008 編譯器 3.5.30729.1 版
版權所有(C) Microsoft Corporation。保留所有權利。

E:\CS\ClrInfo> nmake ClrInfo35.exe
Microsoft (R) 程序維護實用工具 9.00.30729.01 版
版權所有(C) Microsoft Corporation。保留所有權利。

C:\Windows\Microsoft.NET\Framework\v3.5\csc.exe -out:ClrInfo35.exe ClrInfo.cs RuntimeFramework.cs -r:WindowsBase.dll
適用于 Microsoft(R) .NET Framework 3.5 版的 Microsoft(R) Visual C# 2008 編譯器 3.5.30729.1 版
版權所有(C) Microsoft Corporation。保留所有權利。

E:\CS\ClrInfo> nmake ClrInfo40.exe
Microsoft (R) 程序維護實用工具 9.00.30729.01 版
版權所有(C) Microsoft Corporation。保留所有權利。

C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe -out:ClrInfo40.exe ClrInfo.cs RuntimeFramework.cs
 -r:C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\WindowsBase.dll
Microsoft (R) Visual C# 2010 Compiler version 4.0.30319.1
Copyright (C) Microsoft Corporation. All rights reserved.

E:\CS\ClrInfo> dir *.exe
2010/04/17  19:59             7,168 ClrInfo20.exe
2010/04/17  19:59             7,168 ClrInfo35.exe
2010/04/17  19:59             7,680 ClrInfo40.exe

　　使用 Sun VirtualBox 全新安裝 Microsoft Windows Server 2003 R2 Enterprise Edition Service Pack 2 操作系統：

　　運行 ClrInfo35.exe，結果如下所示：

　　運行 ClrInfo40.exe，結果如下所示：

　　好吧，讓我們安裝 Microsoft .NET Framework 2.0 SP2 吧

By Alva Chien

Part I: Basics of the Microsoft .NET Framework

Chapter 1: The Architecture of the .NET framework Development Platform

1.       .Net中的common language runtime (CLR) 是一個可以被多個不同語言使用的runtime. 不管使用哪種編譯器，所生成的結果都是一個managed module. 一個managed module是一個標準的Windows Portable executable (PE) 文件，這個文件必須由CLR來執行.

一個managed module的組成:

2.       一個 assembly是一個或多個managed modules/資源文件的邏輯組合, 它是最小的可重用，擁有版本信息和安全信息的單元. PE文件包含一塊叫做manifest的數據塊. 一個manifest是另一個metadata tables的集合. 這些tables定義了組成一個assembly的文件, 由這些文件定義的exported types, 跟這個assembly關聯的資源或數據文件. 一個典型的例子: 把一些較少使用的types或資源定義在assembly的一個獨立文件中，這個文件只會在其中的type或資源被使用的時候才被加載.

3.       可以通過查找MSCorEE.dll 文件來判斷.NET是否被安裝，這個文件位于%windir%\system32 文件夾中. 但是，一臺機器允許同時安裝幾個版本的.Net Framewor.可以通過查看一下注冊表的鍵值來判斷當前.NET的版本: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy

4.       如何裝載 CLR:

• 當創建一個EXE assembly, 編譯器/鏈接器在生成的assembly’s PE file header嵌入一些特別的信息在.text section.
• 當創建一個DLL assembly, 如果一個unmanaged程序調用LoadLibrary 裝載它, 這個DLL’s 入口函數知道如果裝載CLR來正確處理assembly中的代碼.

5.       當創建一個EXE assembly, 一個的6字節的x86 sub function被嵌入到.text section: JMP _CoreExeMain. 這個_CoreExeMain函數從MSCorEE.dll導入, 這個MSCoreEE.dll (Microsoft Component Object Runtime Execution Engine) 在assembly file’s .idata section定義了引用. 所以當assembly像正常程序一樣啟動時, MSCoreEE.dll被導入到這個進程的地址空間, 這時_CorExemain 函數的地址被獲取，同時JMP instruction被執行. 這個函數將初始化CLR并且查找這個可執行assembly’s CLR header的可執行入口方法，這個方法的IL代碼將被編譯為native CPU instructions， 隨后CLR跳轉這個native code, 這時，程序已經啟動.

6.       當創建一個DLL assembly, 一個類似的6字節長的x86 stub function被嵌入到.text section: JMP _CorDllMain. _CorDllMain 函數同樣從MSCorEE.dll中引入, 這個DLL’s .idata section 中包含MSCorEE.dll的引用定義. 所以, 當LoadLibrary 執行時, _CorDllMain 被調用來初始化CLR并返回給應用程序來繼續執行.

7.       這個6字節的stub function僅僅在非Windows XP系統中被添加. 在Windows XP以及以后版本中, OS loader檢查嵌入managed code的文件的PE file header的directory entry 14. (IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR定義在WinNT.h) 如果這個directory entry存在并且擁有一個非0值, OS loader忽略這個文件的導入 (.idata) section并且自動裝載MSCorEE.dll到進程的地址空間并直接跳轉到對應的函數.

8.       最后一個關于managed PE文件的注意點: 他們總是使用32位PE文件格式, 而不是64位PE文件格式. 在64位系統上, OS loader檢查這個managed 32位PE文件并知道如何去創建一個64位地址空間.

9.       至于知識產權保護, 對于所有的編譯位IL的代碼并且IL代碼能被很容易被Disassembler程序reverse, 可以使用一個第三方提供的obfuscator工具. 這些工具“scramble” managed module’s metadata中所有private symbols的名稱. 另外，可以把一些代碼編譯為unmanaged DLL并在assembly中調用它.

10.   所有的高級語言都只是提供了CLR的一個功能子集. 但是，IL提供了CLR所有的功能.

11.   如果Assembly中的一個方法第一次被調用，它的IL代碼需要被編譯為native CPU代碼, 這部分功能由CLR’s JIT (just-in-time)完成. JIT編譯器在內存中保存了native CPU instructions, 所以當應用程序終止時候，編譯的代碼都將失效. 另外一個值得記住的重點是JIT編譯過程當中有一個專門的優化編譯代碼的過程.

12.   Microsoft .Net framework提供了一個名為NGen.exe的工具; 這個工具編譯一個assembly的全部IL代碼為native CPU代碼并將結果保存到一個硬盤文件.

13.   IL是一個stack-based的語言, 所有的IL instructions會把operands壓棧，并將結果彈出. IL沒有提供操作CPU寄存器的指令.

Kent Sharkey: The Technical Evangelist role is always good for a smile. There aren't too many companies willing to call people that. Basically, our role is to go forth into the community to introduce developers to technologies that aren't shipping yet. We are the advance scouts, if you will, preparing people for changes to come.

RL: In your own words, how would you define the goals and strategy Microsoft is using to merge existing (and future) mobile technology with the larger concept of ".NET"?

KS: Good one. If you think of the overall goal of .NET as helping programs (and people) to communicate better it becomes clearer. Today, and in the past, this has been fairly difficult in the mobile space. People needed to be mobile experts, and used primitive tools to craft apps for Pocket PC or phones. Microsoft is attempting to make this easier for developers, and to enable new forms of applications by doing this.

RL: More specifically, how would you define the .NET Compact Framework and Microsoft's goals in developing it?

KS: The .NET Compact Framework is a lightweight version of the .NET Framework, designed to work well with resource constrained devices. The execution engine and garbage collection has been tightened up, to help with devices where overall memory is still measured in MB. In addition, our support for important standards on the device, such as XML and SOAP support, as well as strong database support with SQL CE are a first in the industry. (well, maybe not the strong database support, but hopefully you're with me) What the .NET Compact Framework is doing is giving developers a set of tools that span devices through servers with a single, consistent programming model.

RL: The .NET Compact Framework and Mobile Internet Toolkit are 2 opposing Microsoft technologies that can be used to develop mobile applications with .NET. Generally speaking, what types of applications do you see as best suited for each of these? What are the key differences between them in terms of development tools, programming techniques, development costs, deployment procedures, and end-user experiences.

KS: I wouldn't say that they were opposing, but complementary. Think of them as the device analogs of Windows Forms (.NET Compact Framework) and Web Forms (MMIT). They both have their place, and optimal usage model. In the case of MMIT, the idea is really reach -- MMIT is great for moving your web applications out to a wide variety of devices, phones, etc. It is a great extension to the ASP.NET model. It's problem is the types of devices it typically targets -- cell phones. They typically have poor data entry capabilities. As such, I would say that MMIT is best for apps that don't require a good deal of data entry, and where the amount of data displayed is relatively small (again, due to phone limitations). Finally, MMIT is best suited for always online applications. .NET Compact Framework, on the other hand, brings a few neat items to the table. First up, through either the larger memory on the device and/or SQL CE, it has data storage capabilities. Therefore, .NET Compact Framework is great for applications that spend part of 'their life' disconnected. SQL CE replication allows you to merge your data back into SQL Server as needed (when connected). Second, .NET Compact Framework gives you the richer capabilities of the device UI. You can use controls such as TreeView, ListView and (soon), DataGrid in your applications without having to struggle with a cross platform DHTML solution. The application could also be faster, as no return time is required to retrieve data. Finally, the development model of .NET Compact Framework is just the same as that of desktop Windows Forms, allowing a developer to move freely and easily between developing for the device and the desktop. MMIT has a somewhat different programming model, possibly confusing some.

RL: As a "Technical Evangelist" you recruit developers to use emerging technology. When doing this, who is your target audience? In other words, what types of organizations do you see as being the best candidates for quickly adopting the .NET Compact Framework? Who do you predict will be (or currently are) the early adopters of this technology?

KS: I look at the target audience as being in two main groups. First, there are those groups doing device development today. .NET Compact Framework gives this group a rich set of tools and consistency with the desktop that will help their move forward. Second, there are those who have never done device development. This is the very exciting group, as .NET Compact Framework means that they can now extend their existing applications to the device easily. They no longer have to learn a new programming environment, with new tools and languages.

RL: Through your interactions with the developer community, what have you found to be the most compelling reasons given for adopting the .NET Compact Framework? Conversely, what reasons have been given for NOT adopting the technology?

KS: The most compelling reason for me is that it uses the same tool and programming model as you develop on the desktop. The consistency between .NET and the .NET Compact Framework means that you already know how to do most things on the device. You build both in Visual Studio .NET. As for reasons for NOT adopting the technology, well, I'm just the wrong person to ask that. There isn't any.

More seriously, some of the companies I've spoken with have decided not to move to .NET Compact Framework because they are already working with (and happy with) Embedded Visual C++ or Embedded Visual Basic. Particularly for small developer shops, that have already scaled the learning curve to get their code on the device 'the hard way', the added training time does not make economic sense.

RL: What advice can offer for developers who have already created and deployed applications for the Windows CE platform using Embedded Visual Basic and/or Embedded Visual C++? What factors should be considered when deciding between maintaining existing code or rewriting applications with the .NET Compact Framework?

KS: The answer is easier for the Embedded Visual Basic people, so I'll start there.

Many of the eVB customers that I've spoken to have been happy with the product. Others, however, feel that there is a 'glass ceiling' to the product. If you try to do applications that go beyond this barrier, it becomes quite difficult. In addition, the fact that it was limited to VBScript was quite limiting. For these developers, we have only good news. Now, they have the full VB .NET language, with the Compact Framework of classes to create their applications with.

Embedded Visual C++ developers, on the other hand do have a choice to make. If they need absolute control of the device, and they're happy developing with eVC, I often encourage them to continue. Those that want to create Web Services, or otherwise take advantage of the functionality available with the .NET Compact Framework, however, should do more than look at .NET Compact Framework. They will find that C# is an amazingly easy language to learn, and the framework does make doing a lot of stuff very easy.

<!-- FIN ARTICLE -->