每个.NET 开发人员应该下载的十个必备工具 原文出处:.NET Tools:Ten Must-Have Tools Every Developer Should Download Now
本文使用了以下技术:.NET,C#,Visual Basic .NET,Visual Studio .NET System.Diagnostics.Process proc = new System.Diagnostics.Process(); 当然该代码片段本身无法编译,而这正是 Snippet Compiler 的用武之地。Figure 1 显示了 Snippet Compiler 中的这一代码示例。 <%@ CodeTemplate Language="C#" 模板的下一部分是属性声明,在这里可声明将在模板每次运行时指定的属性。就该模板而言,我要使用的唯一属性只是一个字符串,因此属性声明如下所示: <%@ Property Name="ClassName" Type="String" Category="Context" 该属性声明将使 ClassName 属性出现在 CodeSmith 属性窗口中,以便可以在模板运行时指定它。下一步是实际生成模板主体,它非常类似于用 ASP.NET 进行编码。你可以在 Figure 3 中查看该模板的主体。[编辑更新 — 6/16/2004:Figure 3 中的代码已被更新,以便对多线程操作保持安全。] using System;下一步,我将创建一个方法并用 [Test] 属性标记它,以便 NUnit 知道该方法是一个测试。然后,我将建立一个 Hashtable 并向其添加两个值,再使用 Assert.AreEqual 方法查看我是否可以检索到与我添加到 Hashtable 的值相同的值,如下面的代码所示: [Test]这将确认我可以首先向 Hashtable 中添加值并随后检索相应的值 — 这是一个很简单的测试,但能够表现 NUnit 的功能。存在许多测试类型以及各种 Assert 方法,可使用它们来测试代码的每个部分。 要运行该测试,我需要生成项目,在 NUnit 应用程序中打开生成的程序集,然后单击 Run 按钮。Figure 5 显示了结果。当我看到那个大的绿色条纹时,我有一种兴奋和头晕的感觉,因为它让我知道测试已经通过了。这个简单的示例表明 NUnit 和单元测试是多么方便和强大。由于能够编写可以保存的单元测试,并且每当你更改代码时都可以重新运行该单元测试,你不仅可以更容易地检测到代码中的缺陷,而且最终能够交付更好的应用程序。 Figure 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” FxCop .NET 框架非常强大,这意味极有可能创建优秀的应用程序,但也同样存在创建劣质程序的可能。FxCop 是有助于创建更好的应用程序的工具之一,通过分析程序集,并使用许多不同的规则来检查它是否符合这些规则。FxCop 随附了由 Microsoft 创建的一组规则,你也可以创建并包括你自己的规则。例如,如果你决定所有的类都应该具有一个不带任何参数的默认构造函数,则可以编写一条规则,以确保程序集的每个类上都具有一个构造函数。这样,无论是谁编写该代码, 你都将获得一定程度的一致性。如果你需要有关创建自定义规则的详细信息,参见 John Robbins 有关这方面的 Bugslayer 专栏文章。 那么,让我们看看实际运行的 FxCop,并且留心一下它在我正在开发的 NUnitExample 程序集中找到什么错误。当你打开 FxCop 时,你首先需要创建一个 FxCop 项目,然后向其添加你要测试的程序集。在将该程序集添加到项目以后,就可以按 Analyze,FxCop 将分析该程序集。Figure 6 显示了 FxCop 在该程序集中找到的错误和警告。 Figure 6 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 程序集。Figure 7 显示了 .NET Reflector 中加载的该程序集。 Figure 7 NUnitExample 程序集 在 .NET Reflector 内部,有各种可用来进一步分析该程序集的工具。要查看构成某个方法的 MSIL,请单击该方法并从菜单中选择 Disassembler。 除了能够查看 MSIL 以外,你还可以通过选择 Tools 菜单下的 Decompiler 来查看该方法的 C# 形式。通过在 Languages 菜单下更改你的选择,你还可以查看该方法被反编译到 Visual Basic .NET 或 Delphi 以后的形式。以下为 .NET Reflector 生成的代码: public void HashtableAddTest()前面的代码看起来非常像我为该方法实际编写的代码。以下为该程序集中的实际代码: public void HashtableAddTest()尽管上述代码中存在一些小的差异,但它们在功能上是完全相同的。 虽然该示例是一种显示实际代码与反编译代码之间对比的好方法,但在我看来,它并不代表 .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 &line; Configuration Properties &line; Build,然后在 XML Documentation File 选项中输入用于保存 XML 文件的路径。当该项目生成时,将创建一个 XML 文件,其中包含所有 XML 注释。下面是 NUnit 示例中的一个用 XML 编写了文档的方法: ///有关该方法的 XML 文档资料将被提取并保存在 XML 文件中,如下所示:
NDoc 使用反射来考察你的程序集,然后读取该文档中的 XML,并且将它们进行匹配。NDoc 使用该数据来创建任意数量的不同文档格式,包括 HTML 帮助文件 (CHM)。在生成 XML 文件以后,下一步是将程序集和 XML 文件加载到 NDoc 中,以便可以对它们进行处理。通过打开 NDoc 并单击 Add 按钮,可以容易地完成该工作。 项目标记还用于设置项目名称、默认目标以及基目录。Description 标记用于设置该项目的简短说明。 接着,我将添加 property 标记,该标记可用于将设置存储到单个位置(随后可以从文件中的任意位置访问该位置)。在该例中,我将创建一个名为 debug 的属性,我可以随后将其设置为 true 或 false,以反映我是否要在调试配置下编译该项目。(最后,这一特定属性并未真正影响如何生成该项目;它只是你设置的一个变量,当你真正确定了如何生成该项目时将读取该变量。) 接下来,我需要创建一个 target 标记。一个项目可以包含多个可在 NAnt 运行时指定的 target。如果未指定 target,则使用默认 target(我在 project 元素中设置的 target)。在该示例中,默认 target 是 build。让我们观察一下 target 元素,它将包含大多数生成信息: 在 target 元素内,我将把 target 的名称设置为 build,并且创建有关该 target 将做哪些工作的说明。我还将创建一个 csc 元素,该元素用于指定应该传递给 csc C# 编译器的数据。让我们看一下该 csc 元素: 首先,我必须设置该 csc 元素的 target。在该例中,我将创建一个 .dll 文件,因此我将 target 设置为 library。接下来,我必须设置 csc 元素的 output,它是将要创建 .dll 文件的位置。最后,我需要设置 debug 属性,它确定了是否在调试中编译该项目。因为我在前面创建了一个用于存储该值的属性,所以我可以使用下面的字符串来访问该属性的值:$&leftsign;debug&rightsign;。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.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 框架的版本。 Figure 9 ASP.NET 版本转换器 Figure 9 显示了实际运行的 ASP.NET 版本转换器。它的使用方法非常简单,只须选择相应的应用程序,然后选择你希望该应用程序使用的 .NET 框架版本。该工具随后将使用 aspnet_regiis.exe 命令行工具将该应用程序转换到所选版本的框架。随着将来版本的 ASP.NET 和 .NET 框架的发布,该工具将变得更为有用。 ASP.NET 版本转换器由 Denis Bauer 编写,下载地址是:http://www.denisbauer.com/NETTools/ASPNETVersionSwitcher.aspx Visual Studio .NET 项目转换器(参见Figure 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),并在必要时进行反向转换。 Figure 10 Visual Studio .NET 项目转换器 Visual Studio .NET 项目转换器由 Dacris Software 编写。下载地址是:http://www.codeproject.com/macro/vsconvert.asp 总结 本文采用走马观花的方式介绍了上述工具,但我已经试图起码向你提供足够的信息以激起你的好奇心。我相信本文已经让你在某种程度上领悟了几个免费工具,你可以立即开始使用这些工具来编写更好的项目。同时,我还要敦促 你确保自己拥有所有其他可以获得的合适工具,无论是最新版本的 Visual Studio、功能强大的计算机还是免费的实用工具。拥有合适的工具将使一切变得大不相同。 |
作者简介 James Avery 是一位使用 .NET 和其它微软技术的顾问。他撰写了许多书籍和文章,其最新著作是《ASP.NET Setup and Configuration Pocket Reference》(Microsoft Press, 2003)。你可以通过 javery@infozerk.com 向他发送电子邮件,并且在 http://www.dotavery.com/blog 阅读他的网络日记。 |
http://download.cnblogs.com/william_fire/archive/2005/01/13/91035.html
.NET我曾经尝试用过了大量的工具,现在说说我推荐的工具吧:)
源码查看工具:
Reflector
不多说了。
加密与混淆工具:
Xeno2005
引用别人的介绍:一款为.NET平台下的开发人员设计的功能强大、灵活和易于使用的代码保护及优化的工具,该软件的.NET分析和重编译引擎保护用户的代码反编译,提高增强程序性能以及提供对.NET框架的支持,包括MC++和Satellite Assemblies
数据库建模工具:
Visio
针对于Sql Server 2000,可以采用Visual Studio2003光碟包中自带的Visio,支持正向生成与反向工程。但Visio在针对其它数据库的支持上有许多问题存在,具体的问题列表,可以查看Visio安装目录上的文档说明。Visio无论用于数据库模型建模还是ORM建型,操作都十分简便。同时也支持鼠标中键缩放视图,非常不错。Visio2003虽然界面漂亮,但仅有反向工程能力,是最大的弊病。
PowerDesign
非常不错的建模工具,支持多种数据库,相对于Visio的版面来说PowerDesign提供了近乎无限大的空间,当然这是仁者见仁,智能见智的问题,但PowerDesign提供了非常强大的反向落工程能力,在反向出来的数据库模型图上,会智能地摆放各个模型所在的位置,尽力做到线路不交叉,同时支持鼠标中键缩放,非常不错。不足之处在于,在模型图上输入或修改字段时,必须打开一个界面不是很友好的界面,无论是初学者还是常用这个工具的人,都会感到烦燥不已。另外,软件的界面不好看,默认字体过小。
Visual Studio.Net 2003
严格地说,vs2003并没有建模能力,因为它仅对Sql Server2000提供较好的支持,但它可以在服务管理器上直接对数据库进行新增和删除表、视图、存储过程的操作,同时也支持在直接画Sql Server的关系图,自定义模型视图的显示方式非常不错,而且在使用起来非常简洁,但可惜的是GDI+的性能是它的使用瓶颈,在图表过数量过多的时候,对内存占用非常大,显示速度也受到影响,让人感觉很差。
ERWin
经典的数据库建模工具,但现在好像已经没有怎么更新了,至少我不清楚。它提供简洁明了的视图进行数据库建模,但不支持鼠标中键的缩放,难免会带来极大的不便,另外,它的新增、修改、添加字段,也是令人不爽的地方,使用起来并不方便,界面不是很友好。但总得来说,它提供了多种数据库的支持,同时也有大量的数据库建模人员在使用它,所以它仍有它独特的价值与魅力。
测试工具
nunit
Nunit是驱动测试开发中的非常不错的工具,如果没有Nunit,测试驱动开发要么会成为空谈,要么会变得很复杂,不过,Nunit,也许是太过于注重简洁,界面过于简单,提供的功能并不多,但无论如何,作为一个经典的软件,它仍是我们软件工具箱中,必不可少的。
TestDriven
TestDriven的前身是Nunit Addin,它把Nunit结合到了vs.net2003的Addin之中,使得开发人员在开发的过程中,不必再去费神开启Nunit,带来了一定的便利性,但更值得一提的是,这里面还提供了MbUnit,MbUnit除了提供了类似于Nunit工具的功能以外,更提供了大量的分析数据报表,可以让开发人员在开发过程中,获取更为详细的分析数据,不过,我个人认为这些功能在开发过程有时候并不必要。但如果把MbUnit应用在每日构建之中,相信将会带来更好的结果。
Parasoft.TEST
刚看到介绍的时候,就对这个东西感兴趣了,我尝试安装了,由于它是基于java的。我一开始很怀疑它的性能,不过在试用了之后,感觉它还是不错的,它可以对.Net程序进行单元测试的工具,并且不需要写测试脚本,可以让开发人员轻松的点击一个按钮就自动进行动态和静态测试源代码,但它对中文源码支持非常不好。
Compuware.DevPartner.Studio
如果不提到这个工具,我认为本文也没有写出来的必要了,这个工具内部包括了非常优秀功能,比如对代码规范性检测,对内存情况分析,对代码分析并提供优化建议,并且还有一个十分令人意外的功能,就是它可以找到你的一个方法引用了哪些类或方法,并用图表现出来,在这一点上做得十分不错。另外,它对中文源码的提供了部分的支持,在某些情况下,仍然也会出现乱码,但不管怎么说,这款软件应该是开发人员必备之宝。
重构工具
CSharpRefactory
我不认为它是一个很好的重构工具,首先它只支持C#,而且还经常出错,使用起来,要冒着一定的危险。
C# Refactoring Tool
同样的,也是一个出错出得让人想杀人的那种,虽然赞誉甚多,但我真的没有发现它有什么地方可以让我感觉良好的。
Resharper
这个工具不算是重构工具,因为它还提供了许多其它特点的功能,但在重构工具的工具箱中,我也只有它了。它在重构的支持上,虽然不如java世界里面的IDE工具那么牛,但它毕竟提供了我们不错的功能,可惜对中文源码的支持非常不好。
Together
如果用Together来进行重构的话,还是自己用手来做吧,它虽然重构提供了中文源码的支持,但它的速度,实在是令不敢恭维,它的重构是可以让开发人员生不如死的,在此一点上,给它两颗星,是因为在这方面,毕竟它提供了此功能并支持了中文的源码,在被逼无奈的时候,还是可以用用的。(顺便说一下,它的重构使得我不承认它能算得上是MDA工具)
代码生成
IronWorks
这个工具相对说来,还是很棒,但因为它破解不太好找,也制约了开发人员使用它,还是...呃,算了。
nTierGen
它是一个面对于数据库访问的代码生成工具,感觉上它还只是马马虎虎,不过它生成的代码大大减少了开发人员的工作量。
Monstarillo
非常不错的代码生成工具,也是针对于数据库的代码生成工具,不过,它支持直接生成aspx页面,并提供了相对灵活的配置,还可以指定生成为通过Microsoft Application DataAccess Block生成的数据库访问代码,目前流传的版本是我把它那个那个了一下之后,...嘿嘿,不说了。
CodeSmith
这是一个通用性的代码生成工具,提供了十分灵活的模板配置功能。具体介绍网上已经很多,不再多提。
今天就说到这里,在上述分类中,当然还有大量的好东西,我无法一一尝试,目前就先说到这里吧。