FxCop

　　.NET 框架非常强大，这意味极有可能创建优秀的应用程序，但也同样存在创建劣质程序的可能。FxCop 是有助于创建更好的应用程序的工具之一，通过分析程序集，并使用许多不同的规则来检查它是否符合这些规则。FxCop 随附了由 Microsoft 创建的一组规则，你也可以创建并包括你自己的规则。例如，如果你决定所有的类都应该具有一个不带任何参数的默认构造函数，则可以编写一条规则，以确保程序集的每个类上都具有一个构造函数。这样，无论是谁编写该代码， 你都将获得一定程度的一致性。如果你需要有关创建自定义规则的详细信息，参见 John Robbins 有关这方面的 Bugslayer 专栏文章。
　　那么，让我们看看实际运行的 FxCop，并且留心一下它在我正在开发的 NUnitExample 程序集中找到什么错误。当你打开 FxCop 时，你首先需要创建一个 FxCop 项目，然后向其添加你要测试的程序集。在将该程序集添加到项目以后，就可以按 Analyze，FxCop 将分析该程序集。
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 程序集。
在 .NET Reflector 内部，有各种可用来进一步分析该程序集的工具。要查看构成某个方法的 MSIL，请单击该方法并从菜单中选择 Disassembler。
　　除了能够查看 MSIL 以外，你还可以通过选择 Tools 菜单下的 Decompiler 来查看该方法的 C# 形式。通过在 Languages 菜单下更改你的选择，你还可以查看该方法被反编译到 Visua 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 文件。Figure 8 中显示了完整的生成文件。（你通常还要创建一个干净的 target，用于删除生成的文件，但为了简洁起见，我已经将其省略。）
　　要生成该文件，我需要转到我的项目的根目录（生成文件位于此处），然后从该位置执行 nant.exe。如果生成成功，你可以在该应用程序的 bin 目录中找到 .dll 和 .pdb 文件。尽管使用 NAnt 肯定不像在 Visual Studio 中单击 Build 那样简单，但它仍然是一种非常强大的工具，可用于开发按自动计划运行的生成过程。NAnt 还包括一些有用的功能，例如能够运行单元测试或者复制附加文件（这些功能没有受到当前 Visual Studio 生成过程的支持）。 NAnt 是一个开放源代码项目，下载地址是：http://nant.sourceforge.net/

转换工具

　　我已经将两个独立的工具合在一起放在标题“转换工具”下面。这两个工具都非常简单，但又可能极为有用。第一个工具是 ASP.NET 版本转换器，它可用于转换 ASP.NT（虚拟目录在它下面运行）的版本。
　　当 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 框架的版本。

　　它的使用方法非常简单，只须选择相应的应用程序，然后选择你希望该应用程序使用的 .NET 框架版本。该工具随后将使用 aspnet_regiis.exe 命令行工具将该应用程序转换到所选版本的框架。随着将来版本的 ASP.NET 和 .NET 框架的发布，该工具将变得更为有用。
　　ASP.NET 版本转换器由 Denis Bauer 编写，Visual Studio .NET 项目转换器非常类似于 ASP.NET 版本转换器，区别在于它用于转换 Visual Studio 项目文件的版本。尽管在 .NET 框架的 1.0 版和 1.1 版之间只有很小的差异，但一旦将项目文件从 Visual Studio .NET 2002 转换到 Visual Studio .NET 2003，将无法再把它转换回去。虽然这在大多数时候可能不会成为问题，但在某些时刻你可能需要将项目转换回去。