.NET开源环境
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了,反正这不是必须的选择不是关键路径,不管它了。但至少可以看到"开放"跟"黑盒子"的区别,象没头的苍蝇乱撞一通,最后只能屈服。想想工作的这么多年,多少疑难杂症的处理情形,都跟这差不多的。相比而言如果使用一个开源项目,只要源码看的够仔细、思想理解够透彻,大大小小的问题就总是能快速定位,大不了跟踪到里面转几圈也就明白了。
黑盒子给使用者知识的获得造成障碍;给故障的分析、解决带来高成本;自身的改变给之前用户已积累的经验造成破坏,甚至是根本性的推倒重来。
商业利益为第一位的开发工具、平台,所有用户都在商业法则的重压下生存,商业法则的无情对应到用户的无辜;自由、开源的世界中,不管程度深浅,总有共享精神的存在,这是对禁锢的松解。不同的开源协议,只是在自由、责任、权利与商业利益之间不同程度的权衡。
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了,反正这不是必须的选择不是关键路径,不管它了。但至少可以看到"开放"跟"黑盒子"的区别,象没头的苍蝇乱撞一通,最后只能屈服。想想工作的这么多年,多少疑难杂症的处理情形,都跟这差不多的。相比而言如果使用一个开源项目,只要源码看的够仔细、思想理解够透彻,大大小小的问题就总是能快速定位,大不了跟踪到里面转几圈也就明白了。
黑盒子给使用者知识的获得造成障碍;给故障的分析、解决带来高成本;自身的改变给之前用户已积累的经验造成破坏,甚至是根本性的推倒重来。
商业利益为第一位的开发工具、平台,所有用户都在商业法则的重压下生存,商业法则的无情对应到用户的无辜;自由、开源的世界中,不管程度深浅,总有共享精神的存在,这是对禁锢的松解。不同的开源协议,只是在自由、责任、权利与商业利益之间不同程度的权衡。