NDoc很不错，可是M$出个SandCastle，基本跟NDoc差不多，NDoc项目停止了。
NUnit很不错，尤其是在TDD的潮流下越来越成为必不可少的工具，然后VS IDE中有了TestProject，看看Unit Test，做法跟NUnit差不多，不知道NUnit项目能维持到什么时候。
NAnt呢，只知道VS中有了MSBuild，这个就不了解了。
LINQ出来了，一段时间后不知道NHibernate等ORM项目是否还有前途。
还有很多优秀的开源项目，是不是当绝大部分人都觉得它们是优秀的项目时，也就意味着这个项目快走到尽头了？
不知道这些项目是以某种方式的合作而转移，还是因为形势的发展而被迫停止了。
不知道这对.NET开发人员而言，对.NET的发展而言，是好事还是坏事。
不过呢，开源项目的开放性，对我来讲非常有用。而做同一件事情，当我不得不选择封闭的商业软件时，总是存在束缚。
1. 不少的开源项目采用的协议支持商业用途+源码修改再发布，这样你拥有完全的控制权，就算开源项目停止了更新升级，你也可以自己去做，你总是有机会让它满足你的项目需求、解决它产生的问题。
2. 源代码的开放使你能完全的了解任何一个处理细节，而不是一个黑盒子让你不知所措，遇到屁大一点问题也只能拿着黑盒子瞎折腾、google，最后可能还得使用技术支持。除了官方文档、牛人的trace/反编译研究分析成果，没有什么太多方式去了解这个黑盒子里面的内容，哪怕它只是屁大一个小工具。
举个例子，今天在VS2008里面试一下Test Project，整体情况跟SharpDevelop集成NUnit一样，可以直接在IDE中启动Unit Test调试，用起来比较方便。但碰到个问题，就是SharpDevelop + MySql
这篇Post中遇到的，问题现象：
用NHibernate开发，MySQL数据库，NHibernate用反射创建MySql.Data的IDbConnection、IDbCommand对象。为了开发调试的一些原因导致测试目录下面必须有MySql.Data.dll这个文件，反射才能创建成功。
OK，使用NUnit时没有关系，可以把dll直接拷贝到测试目录中。
SharpDevelop集成NUnit，它的方式是在C盘动态创建一个运行测试的目录，调试时把相关dll文件拷贝到这个目录下，然后启动NUnit插件。所以我只需要在测试工程中引用MySql.Data，在引用属性上选择将这个dll拷贝到本地（Copy Local=True）就好了。
VS2008的Test工程，做法跟SharpDevelop差不多，是在当前解决方案的目录下创建一个TestResults目录，每一次运行测试都会在这个目录下创建一个子目录，用于当前测试。子目录的命名规则，可以在测试工程的LocalTestRun.testrunconfig上面做一些配置。问题来了，在测试工程中引用MySql.Data，选择拷贝到本地，但测试运行时VS2008没有将这个dll拷贝到测试目录下（如果将GAC里面的MySql.Data干掉是否可以？没有尝试了）。然后试着直接将dll拷贝到测试目录，但郁闷的发现不管怎么配置，每次测试时都会重新创建一个新的子目录，用于当前测试。尝试Setup and Cleanup Scripts等都不行，因为测试目录一直变化，没辙，都走不通。
Over了，反正这不是必须的选择不是关键路径，不管它了。但至少可以看到"开放"跟"黑盒子"的区别，象没头的苍蝇乱撞一通，最后只能屈服。想想工作的这么多年，多少疑难杂症的处理情形，都跟这差不多的。相比而言如果使用一个开源项目，只要源码看的够仔细、思想理解够透彻，大大小小的问题就总是能快速定位，大不了跟踪到里面转几圈也就明白了。
黑盒子给使用者知识的获得造成障碍；给故障的分析、解决带来高成本；自身的改变给之前用户已积累的经验造成破坏，甚至是根本性的推倒重来。
商业利益为第一位的开发工具、平台，所有用户都在商业法则的重压下生存，商业法则的无情对应到用户的无辜；自由、开源的世界中，不管程度深浅，总有共享精神的存在，这是对禁锢的松解。不同的开源协议，只是在自由、责任、权利与商业利益之间不同程度的权衡。