企業開發應該下載的十種工具

本文討論：

•	用於編寫單元測試的 NUnit
•	用於建立代碼文檔資料的 NDoc
•	用於產生解決方案的 NAnt
•	用於產生代碼的 CodeSmith
•	用於監視代碼的 FxCop
•	用於編譯少量代碼的 Snippet Compiler
•	兩種不同的轉換器工具：ASP.NET 版本轉換器和 Visual Studio .NET 項目轉換器
•	用於產生Regex的 Regulator
•	用於剖析器集的 .NET Reflector

本文使用了下列技術：

.NET、C# 或 Visual Basic .NET、Visual Studio .NET

除非您使用能夠獲得的最佳工具，否則您無法期望產生一流的應用程式。除了像 Visual Studio.NET 這樣的著名工具以外，還可以從 .NET 社區獲得許多小型的、不太為人所知的工具。在本文中，我將向您介紹一些目前可以獲得的、面向 .NET 開發的最佳免費工具。我將引導您完成一個有關如何使用其中每種工具的快速教程 — 一些工具在許多時候可以使您節約一分鐘，而另一些工具則可能徹底改變您編寫代碼的方式。因為我要在本篇文章中介紹如此之多的不同工具，所以我無法詳盡討論其中每種工具，但您應該瞭解到有關每種工具的足夠資訊，以便判斷哪些工具對您的項目有用。

本頁內容

	Snippet Compiler
	Regulator
	CodeSmith
	產生自訂模板
	NUnit
	編寫 NUnit 測試
	FxCop
	Lutz Roeder 的 .NET Reflector
	NDoc
	NAnt
	實際啟動並執行 NAnt
	轉換工具
	小結

Snippet Compiler

Snippet Compiler 是一個基於 Windows 的小型應用程式，您可以通過它來編寫、編譯和運行代碼。如果您具有較小的程式碼片段，並且您不希望為其建立完整的 Visual Studio .NET 項目（以及伴隨該項目的所有檔案），則該工具將很有用。

例如，假設我希望向您說明如何從 Microsoft?.NET 架構中啟動另一個應用程式。在 Snippet Compiler 中，我將通過建立一個能夠建立小型控制台應用程式的檔案開始。可以在該控制台應用程式的 Main 方法內部建立程式碼片段，而這正是我要在這裡做的事情。下面的程式碼片段示範了如何從 .NET 架構中建立記事本執行個體：

System.Diagnostics.Process proc = new System.Diagnostics.Process();proc.StartInfo.FileName= "notepad.exe";proc.Start();proc.WaitForExit();

當然該程式碼片段本身無法編譯，而這正是 Snippet Compiler 的用武之地。圖 1 顯示了 Snippet Compiler 中的這一程式碼範例。

圖 1 Snippet Compiler

要測試該程式碼片段，只須按 play（運行）按鈕（綠色三角形），它就會在偵錯模式下運行。該程式碼片段將產生一個彈出式控制台應用程式，並且將顯示記事本。當您關閉記事本時，該控制台應用程式也將關閉。

就我個人而言，我是在嘗試為某位向我求助的人士建立一個小型樣本時，才發現 Snippet Compiler 是如此寶貴的 — 如果不使用該工具，則我通常必須建立一個項目，確保每個部分都能編譯通過，然後將程式碼片段發送給求助者，並刪除該項目。Snippet Compiler 使得這一過程變得更加容易、更加愉快。

Snippet Compiler 由 Jeff Key 編寫，並且可以從 http://www.sliver.com/dotnet/SnippetCompiler 下載。

返回頁首

Regulator

Regulator 是最後一個添加到我的頭等工具清單中的。它是一種很有特色的工具，能夠使產生和測試Regex變得很容易。人們對Regex重新產生了興趣，因為它們在 .NET 架構中受到很好的支援。Regex用來基於字元、頻率和字元順序定義字串中的模式。它們最常見的用途是作為驗證使用者輸入有效性的手段或者作為在較大字串中尋找字串的方法 — 例如，在 Web 頁上尋找 URL 或電子郵件地址。

Regulator 使您可以輸入一個Regex以及一些針對其運行該運算式的輸入內容。這樣，在應用程式中實現該Regex之前，您可以瞭解它將產生什麼效果以及它將返回哪些種類的匹配項。圖 2 顯示了帶有簡單Regex的 Regulator。

文檔中包含該Regex — 在該樣本中，它是 [0-9]*，應該匹配一行中任意數量的數字。右下側的框中含有針對該Regex的輸入，而左下側的框顯示了該Regex在輸入內容中找到的匹配項。在這樣的單獨應用程式中編寫和測試Regex，要比嘗試在您的應用程式中處理它們容易得多。

Regulator 中的最佳功能之一是能夠在 regexlib.com 搜尋聯機Regex庫。例如，如果您在搜尋方塊中輸入字串“phone”，您將找到 20 種以上能夠匹配各種電話號碼的不同的Regex，包括用於英國、澳大利亞的運算式以及其他許多電話號碼。Regulator 由 Roy Osherove 編寫，並且可以在 http://royo.is-a-geek.com/regulator 下載。

返回頁首

CodeSmith

CodeSmith 是一種基於模板的代碼產生工具，它使用類似於 ASP.NET 的文法來產生任意類型的代碼或文本。與其他許多代碼產生工具不同，CodeSmith 不要求您訂閱特定的應用程式設計或體繫結構。使用 CodeSmith，可以產生包括簡單的強型別集合和完整應用程式在內的任何東西。

當您產生應用程式時，您經常需要重複完成某些特定的任務，例如編寫資料存取碼或者產生自訂集合。CodeSmith 在這些時候特別有用，因為您可以編寫模板自動完成這些任務，從而不僅提高您的工作效率，而且能夠自動完成那些最為乏味的任務。CodeSmith 附帶了許多模板，包括對應於所有 .NET 集合類型的模板以及用於產生預存程序的模板，但該工具的真正威力在於能夠建立自訂模板。為了使您能夠入門，我將快速介紹一下如何產生自訂模板。

返回頁首

產生自訂模板

CodeSmith 模板只是一些可以在任意文字編輯器中建立的文字檔。它們的唯一要求是用 .cst 副檔名來儲存它們。我將要產生的樣本模板將接受一個字串，然後基於該字串產生一個類。建立模板的第一步是添加模板頭，它可聲明模板的語言、目標語言以及簡要模板說明：

<%@ CodeTemplate Language="C#"       TargetLanguage="C#"    Description="Car Template" %>

模板的下一部分是屬性聲明，在這裡可聲明將在模板每次運行時指定的屬性。就該模板而言，我要使用的唯一屬性只是一個字串，因此屬性聲明如下所示：

<%@ Property Name="ClassName" Type="String" Category="Context"     Description="Class Name" %>

該屬性聲明將使 ClassName 屬性出現在 CodeSmith 屬性視窗中，以便可以在模板運行時指定它。下一步是實際產生模板主體，它非常類似於用 ASP.NET 進行編碼。您可以在圖 3 中查看該模板的主體。[編輯更新 — 6/16/2004：圖 3 中的代碼已被更新，以便對多線程操作保持安全。]

正如您所見，該模板接受字串輸入並使用該類名產生單獨的類。在模板主體中，使用與 ASP.NET 中相同的起始和結束標記。在該模板中，我只是插入屬性值，但您還可以在這些標記內部使用任意類型的 .NET 代碼。在該模板完成之後，您就可以通過雙擊它或者從 CodeSmith 應用程式中開啟它將其載入到 CodeSmith 中。圖 4 顯示了已經載入到 CodeSmith 中的該模板。

您可以看到左側的屬性正是我在該模板中聲明的屬性。如果我輸入“SingletonClass”作為類名，並單擊 Generate 按鈕，則將產生圖 3 的底部顯示的類。

CodeSmith 使用起來相當容易，如果能夠正確應用，則可以產生一些令人難以置信的結果。面向代碼產生的應用程式中最常見的部分之一是資料訪問層。CodeSmith 包括一個名為 SchemaExplorer 的特殊的程式集，可用來從表、預存程序或幾乎任何其他 SQL Server? 對象產生模板。

CodeSmith 由 Eric J. Smith 編寫，並且可以在 http://www.ericjsmith.net/codesmith 下載。

返回頁首

NUnit

NUnit 是為 .NET 架構產生的開放原始碼單元測試架構。NUnit 使您可以用您喜歡的語言編寫測試，從而測試應用程式的特定功能。當您首次編寫代碼時，單元測試是一種測試代碼功能的很好方法，它還提供了一種對應用程式進行迴歸測試的方法。NUnit 應用程式提供了一個用於編寫單元測試的架構，以及一個運行這些測試和查看結果的圖形介面。

返回頁首

編寫 NUnit 測試

作為樣本，我將測試 .NET 架構中 Hashtable 類的功能，以確定是否可以添加兩個對象並且隨後檢索這些對象。我的第一步是添加對 NUnit.Framework 程式集的引用，該程式集將賦予我對 NUnit 架構的屬性和方法的訪問權。接下來，我將建立一個類並用 TestFixture 屬性標記它。該屬性使 NUnit 可以知道該類包含 NUnit 測試：

using System;using System.Collections;using NUnit.Framework;namespace NUnitExample{    [TestFixture]    public class HashtableTest {        public HashtableTest() {                    }    }}

下一步，我將建立一個方法並用 [Test] 屬性標記它，以便 NUnit 知道該方法是一個測試。然後，我將建立一個 Hashtable 並向其添加兩個值，再使用 Assert.AreEqual 方法查看我是否可以檢索到與我添加到 Hashtable 的值相同的值，如下面的代碼所示：

[Test]public void HashtableAddTest(){    Hashtable ht = new Hashtable();                ht.Add("Key1", "Value1");    ht.Add("Key2", "Value2");    Assert.AreEqual("Value1", ht["Key1"], "Wrong object returned!");    Assert.AreEqual("Value2", ht["Key2"], "Wrong object returned!");}

這將確認我可以首先向 Hashtable 中添加值並隨後檢索相應的值 — 這是一個很簡單的測試，但能夠表現 NUnit 的功能。存在許多測試類型以及各種 Assert 方法，可使用它們來測試代碼的每個部分。

要運行該測試，我需要產生項目，在 NUnit 應用程式中開啟產生的程式集，然後單擊 Run 按鈕。圖 5 顯示了結果。當我看到那個大的綠色條紋時，我有一種興奮和頭暈的感覺，因為它讓我知道測試已經通過了。這個簡單的樣本表明 NUnit 和單元測試是多麼方便和強大。由於能夠編寫可以儲存的單元測試，並且每當您更改代碼時都可以重新運行該單元測試，您不僅可以更容易地檢測到代碼中的缺陷，而且最終能夠交付更好的應用程式。

圖 5 NUnit

NUnit 是一個開放原始碼項目，並且可以從 http://www.nunit.org 下載。還有一個優秀的 NUnit Visual Studio .NET 增益集，它使您可以直接從 Visual Studio 中運行單元測試。您可以在 http://sourceforge.net/projects/nunitaddin 找到它。有關 NUnit 及其在測試驅動開發中的地位的詳細資料，請參閱文章“Test-Driven C#: Improve the Design and Flexibility of Your Project with Extreme Programming Techniques”（MSDN Magazine 2004 年 4 月刊）。

返回頁首

FxCop

.NET 架構非常強大，這意味著存在建立優秀應用程式的極大可能，但是也同樣存在建立劣質程式的可能。FxCop 是有助於建立更好的應用程式的工具之一，它所採用的方法是：使您能夠剖析器集，並使用一些不同的規則來檢查它是否符合這些規則。FxCop 隨附了由 Microsoft 建立的固定數量的規則，但您也可以建立並包括您自己的規則。例如，如果您決定所有的類都應該具有一個不帶任何參數的預設建構函式，則可以編寫一條規則，以確保程式集的每個類上都具有一個建構函式。這樣，無論是誰編寫該代碼，您都將獲得一定程度的一致性。如果您需要有關建立自訂規則的詳細資料，請參閱 John Robbins 的有關該主題的 Bugslayer 專欄文章（MSDN Magazine 2004 年 6 月刊）。

那麼，讓我們觀察一下實際啟動並執行 FxCop，並且看一下它在我一直在處理的 NUnitExample 程式集中找到哪些錯誤。當您開啟 FxCop 時，您首先需要建立一個 FxCop 項目，然後向其添加您要測試的程式集。在將該程式集添加到項目以後，就可以按 Analyze，FxCop 將分析該程式集。圖 6 中顯示了在該程式集中找到的錯誤和警告。

FxCop 在我的程式集中找到了幾個問題。您可以雙擊某個錯誤以查看詳細資料，包括規則說明以及在哪裡可以找到更多資訊。（您可以做的一件有趣的事情是在架構程式集上運行 FxCop 並查看發生了什麼事情。）

FxCop 可以協助您建立更好的、更一致的代碼，但它無法補償低劣的應用程式設計或非常簡單拙劣的編程。FxCop 也不能替代對等代碼檢查，但是因為它可以在進行代碼檢查之前捕獲大量錯誤，所以您可以花費更多時間來解決嚴重的問題，而不必擔心命名規範。FxCop 由 Microsoft 開發，並且可以從 http://www.gotdotnet.com/team/fxcop 下載。

返回頁首

Lutz Roeder 的 .NET Reflector

下一個必不可少的工具稱為 .NET Reflector，它是一個類瀏覽器和反編譯器，可以剖析器集並向您展示它的所有秘密。.NET 架構向全世界引入了可用來分析任何基於 .NET 的代碼（無論它是單個類還是完整的程式集）的反射概念。反射還可以用來檢索有關特定程式集中包含的各種類、方法和屬性的資訊。使用 .NET Reflector，您可以瀏覽程式集的類和方法，可以分析由這些類和方法產生的 Microsoft 中繼語言 (MSIL)，並且可以反編譯這些類和方法並查看 C# 或 Visual Basic .NET 中的等價類別和方法。

為了示範 .NET Reflector 的工作方式，我將載入和分析前面已經顯示的 NUnitExample 程式集。圖 7 顯示了 .NET Reflector 中載入的該程式集。

圖 7 NUnitExample 程式集

在 .NET Reflector 內部，有各種可用來進一步分析該程式集的工具。要查看構成某個方法的 MSIL，請單擊該方法並從菜單中選擇 Disassembler。

除了能夠查看 MSIL 以外，您還可以通過選擇 Tools 菜單下的 Decompiler 來查看該方法的 C# 形式。通過在 Languages 菜單下更改您的選擇，您還可以查看該方法被反編譯到 Visual Basic .NET 或 Delphi 以後的形式。以下為 .NET Reflector 產生的程式碼：

public void HashtableAddTest(){     Hashtable hashtable1;    hashtable1 = new Hashtable();    hashtable1.Add("Key1", "Value1");    hashtable1.Add("Key2", "Value2");    Assert.AreEqual("Value1", hashtable1["Key1"],        "Wrong object returned!");    Assert.AreEqual("Value2", hashtable1["Key2"],       "Wrong object returned!");}

前面的代碼看起來非常像我為該方法實際編寫的代碼。以下為該程式集中的實際代碼：

public void HashtableAddTest(){    Hashtable ht = new Hashtable();                ht.Add("Key1", "Value1");    ht.Add("Key2", "Value2");    Assert.AreEqual("Value1", ht["Key1"],        "Wrong object returned!");    Assert.AreEqual("Value2", ht["Key2"],        "Wrong object returned!");}

儘管上述代碼中存在一些小的差異，但它們在功能上是完全相同的。

雖然該樣本是一種顯示實際代碼與反編譯代碼之間對比的好方法，但在我看來，它並不代表 .NET Reflector 所具有的最佳用途 — 分析 .NET 架構程式集和方法。.NET 架構提供了許多執行類似操作的不同方法。例如，如果您需要從 XML 中讀取一組資料，則存在多種使用 XmlDocument、XPathNavigator 或 XmlReader 完成該工作的不同方法。通過使用 .NET Reflector，您可以查看 Microsoft 在編寫資料集的 ReadXml 方法時使用了什麼，或者查看他們在從設定檔讀取資料時做了哪些工作。.NET Reflector 還是一個瞭解以下最佳實施策略的優秀方法：建立諸如 HttpHandlers 或配置處理常式之類的對象，因為您可以瞭解到 Microsoft 工作群組實際上是如何在架構中產生這些對象的。

.NET Reflector 由 Lutz Roeder 編寫，並且可以從 http://www.aisto.com/roeder/dotnet 下載。

返回頁首

NDoc

編寫代碼文檔資料幾乎總是一項令人畏懼的任務。我所說的不是早期設計文檔，甚至也不是更為詳細的設計文檔；我說的是記錄類上的各個方法和屬性。NDoc 工具能夠使用反射來剖析器集，並使用從 C# XML 注釋產生的 XML 自動為代碼產生文檔資料。XML 注釋僅適用於 C#，但有一個名為 VBCommenter 的 Visual Studio .NET Power Toy，它能夠為 Visual Basic .NET 完成類似的工作。此外，下一版本的 Visual Studio 將為更多語言支援 XML 注釋。

使用 NDoc 時，您仍然在編寫代碼的技術文檔，但您是在編寫代碼的過程中完成了文檔編寫工作（在 XML 注釋中），而這更容易忍受。使用 NDoc 時，第一步是為您的程式集開啟 XML 注釋產生功能。按右鍵該項目並選擇 Properties | Configuration Properties | Build，然後在 XML Documentation File 選項中輸入用於儲存 XML 檔案的路徑。當該項目產生時，將建立一個 XML 檔案，其中包含所有 XML 注釋。下面是 NUnit 樣本中的一個用 XML 編寫了文檔的方法：

/// <summary>/// This test adds a number of values to the Hashtable collection /// and then retrieves those values and checks if they match./// </summary>[Test]public void HashtableAddTest(){    //Method Body Here}

有關該方法的 XML 文檔資料將被提取並儲存在 XML 檔案中，如下所示：

<member name="M:NUnitExample.HashtableTest.HashtableAddTest">  <summary>This test adds a number of values to the Hashtable collection    and then retrieves those values and checks if they match.</summary> </member>

NDoc 使用反射來考察您的程式集，然後讀取該文檔中的 XML，並且將它們進行匹配。NDoc 使用該資料來建立任意數量的不同文檔格式，包括 HTML 協助檔案 (CHM)。在產生 XML 檔案以後，下一步是將程式集和 XML 檔案載入到 NDoc 中，以便可以對它們進行處理。通過開啟 NDoc 並單擊 Add 按鈕，可以容易地完成該工作。

在將程式集和 XML 檔案載入到 NDoc 中並且使用可用的屬性範圍自訂輸出以後，單擊 Generate 按鈕將啟動產生文檔資料的過程。使用預設的屬性，NDoc 可以產生一些非常吸引人並且實用的 .html 和 .chm 檔案，從而以快速有效方式自動完成原來非常乏味的任務。

NDoc 是一個開放原始碼項目，並且可以從 http://ndoc.sourceforge.net 下載。

返回頁首

NAnt

NAnt 是一個基於 .NET 的產生工具，與目前的版本的 Visual Studio .NET 不同，它使得為您的項目建立產生過程變得非常容易。當您擁有大量從事單個項目的開發人員時，您不能依賴於從單個使用者的座位進行產生。您也不希望必須定期手動產生該項目。您更願意建立每天晚上啟動並執行自動產生過程。NAnt 使您可以產生解決方案、複製檔案、運行 NUnit 測試、寄送電子郵件，等等。遺憾的是，NAnt 缺少漂亮的圖形介面，但它的確具有可以指定應該在產生過程中完成哪些任務的控制台應用程式和 XML 檔案。注意，MSBuild（屬於 Visual Studio 2005 的新的產生平台）為每種健壯的產生方案進行了準備，並且由基於 XML 的專案檔以類似的方式驅動。

返回頁首

實際啟動並執行 NAnt

在該樣本中，我將為前面建立的 NUnitExample 解決方案建立一個 NAnt 版本檔案。首先，我需要建立一個具有 .build 副檔名的 XML 檔案，將其放在我的項目的根目錄中，然後向該檔案的頂部添加一個 XML 聲明。我需要添加到該檔案的第一個標記是 project 標記：

<?xml version="1.0"?><project name="NUnit Example" default="build" basedir=".">    <description>The NUnit Example Project</description></project>

項目標記還用於設定項目名稱、預設目標以及基目錄。Description 標記用於設定該項目的簡短說明。

接下來，我將添加 property 標記，該標記可用於將設定儲存到單個位置（隨後可以從檔案中的任意位置訪問該位置）。在該例中，我將建立一個名為 debug 的屬性，我可以隨後將其設定為 true 或 false，以反映我是否要在調試配置下編譯該項目。（最後，這一特定屬性並未真正影響如何產生該項目；它只是您設定的一個變數，當您真正確定了如何產生該項目時將讀取該變數。）

接下來，我需要建立一個 target 標記。一個項目可以包含多個可在 NAnt 運行時指定的 target。如果未指定 target，則使用預設 target（我在 project 元素中設定的 target）。在該樣本中，預設 target 是 build。讓我們觀察一下 target 元素，它將包含大多數產生資訊：

<target name="build" description="compiles the source code"></target>

在 target 元素內，我將把 target 的名稱設定為 build，並且建立有關該 target 將做哪些工作的說明。我還將建立一個 csc 元素，該元素用於指定應該傳遞給 csc C# 編譯器的資料。讓我們看一下該 csc 元素：

<csc target="library" output="./bin/debug/NUnitExample.dll"     debug="${debug}"><references>    <includes name="C:/program files/NUnit V2.1/bin/NUnit.Framework.dll"/></references>    <sources>       <includes name="HashtableTest.cs"/>    </sources></csc>

首先，我必須設定該 csc 元素的 target。在該例中，我將建立一個 .DLL 檔案，因此我將 target 設定為 library。接下來，我必須設定 csc 元素的 output，它是將要建立 .DLL 檔案的位置。最後，我需要設定 debug 屬性，它確定了是否在調試中編譯該項目。因為我在前面建立了一個用於儲存該值的屬性，所以我可以使用下面的字串來訪問該屬性的值：${debug}。Csc 元素還包含一些子項目。我需要建立兩個元素：references 元素將告訴 NAnt 需要為該項目引用哪些程式集，sources 元素告訴 NAnt 要在產生過程中包含哪些檔案。在該樣本中，我引用了 NUnit.Framework.dll 程式集並包含了 HashtableTest.cs 檔案。圖 8 中顯示了完整的組建檔案。（您通常還要建立一個乾淨的 target，用於刪除產生的檔案，但為了簡潔起見，我已經將其省略。）

要產生該檔案，我需要轉到我的項目的根目錄（組建檔案位於此處），然後從該位置執行 nant.exe。如果產生成功，您可以在該應用程式的 bin 目錄中找到 .dll 和 .pdb 檔案。儘管使用 NAnt 肯定不像在 Visual Studio 中單擊 Build 那樣簡單，但它仍然是一種非常強大的工具，可用於開發按自動計劃啟動並執行產生過程。NAnt 還包括一些有用的功能，例如能夠運行單元測試或者複製附加檔案（這些功能沒有受到當前 Visual Studio 產生過程的支援）。

NAnt 是一個開放原始碼項目，並且可以從 http://nant.sourceforge.net 下載。

返回頁首

轉換工具

我已經將兩個獨立的工具合在一起放在標題“轉換工具”下面。這兩個工具都非常簡單，但又可能極為有用。第一個工具是 ASP.NET 版本轉換器，它可用於轉換 ASP.NET（虛擬目錄在它下面運行）的版本。第二個工具是 Visual Studio Converter，它可用於將專案檔從 Visual Studio .NET 2002 轉換到 Visual Studio .NET 2003。

當 IIS 處理請求時，它會查看正在請求的檔案的副檔名，然後基於該 Web 網站或虛擬目錄的副檔名映射，將請求委派給 ISAPI 擴充或者自己處理該請求。這正是 ASP.NET 的工作方式；將為所有 ASP.NET 副檔名註冊副檔名映射，並將這些副檔名映射導向 aspnet_isapi.dll。這種工作方式是完美無缺的，除非您安裝了 ASP.NET 1.1 — 它會將副檔名映射升級到新版本的 aspnet_isapi.dll。當在 ASP.NET 1.0 上產生的應用程式試圖用 1.1 版運行時，這會導致錯誤。要解決該問題，可以將所有副檔名映射重新轉換到 1.0 版的 aspnet_isapi.dll，但是由於有 18 種副檔名映射，所以手動完成這一工作將很枯燥。這正是 ASP.NET 版本轉換器可以發揮作用的時候。使用這一小型工具 + 生產力，可以轉換任何單個 ASP.NET 應用程式所使用的 .NET 架構的版本。

圖 9 ASP.NET 版本轉換器

圖 9 顯示了實際啟動並執行 ASP.NET 版本轉換器。它的使用方法非常簡單，只須選擇相應的應用程式，然後選擇您希望該應用程式使用的 .NET 架構版本。該工具隨後將使用 aspnet_regiis.exe 命令列工具將該應用程式轉換到所選版本的架構。隨著將來版本的 ASP.NET 和 .NET 架構的發布，該工具將變得更為有用。

ASP.NET 版本轉換器由 Denis Bauer 編寫，並且可以從 http://www.denisbauer.com/NETTools/ASPNETVersionSwitcher.aspx 下載。

Visual Studio .NET 項目轉換器（參見圖 10）非常類似於 ASP.NET 版本轉換器，區別在於它用於轉換 Visual Studio 專案檔的版本。儘管在 .NET 架構的 1.0 版和 1.1 版之間只有很小的差異，但一旦將專案檔從 Visual Studio .NET 2002 轉換到 Visual Studio .NET 2003，將無法再把它轉換回去。雖然這在大多數時候可能不會成為問題（因為在 .NET 架構 1.0 版和 1.1 版之間幾乎沒有什麼破壞性的更改），但在某些時刻您可能需要將項目轉換回去。該轉換器可以將任何解決方案或專案檔從 Visual Studio 7.1 (Visual Studio .NET 2003) 轉換到 Visual Studio 7.0 (Visual Studio .NET 2002)，並在必要時進行反向轉換。

圖 10 Visual Studio .NET 項目轉換器

Visual Studio .NET 項目轉換器由 Dacris Software 編寫。該工具可以從 http://www.codeproject.com/macro/vsconvert.asp 下載。

返回頁首

小結

本文採用走馬觀花的方式介紹了上述工具，但我已經試圖起碼向您提供足夠的資訊以激起您的好奇心。我相信本文已經讓您在某種程度上領悟了幾個免費工具，您可以立即開始使用這些工具來編寫更好的項目。同時，我還要敦促您確保自己擁有所有其他可以獲得的合適工具，無論是最新版本的 Visual Studio、功能強大的電腦還是免費的工具 + 生產力。擁有合適的工具將使一切變得大不相同。

James Avery 是一位使用 .NET 和其他 Microsoft 技術的顧問。他已經撰寫了許多書籍和文章，他的最新著作是《ASP.NET Setup and Configuration Pocket Reference》(Microsoft Press, 2003)。您可以通過 javery@infozerk.com 向他寄送電子郵件，並且在 http://www.dotavery.com/blog 閱讀他的網路日記。

本文摘自 MSDN Magazine 的 2004 年 7 月刊。