jba*_*ndi 72 .net build-automation build-process maven-2 build
我的印象是,在.NET世界中,并不需要像Maven这样的工具.
我知道有Byldan和NMaven(它还活着吗？),但我还没有看到使用它们的真实项目.
同样在我工作的大多数.NET项目中,从未有人表示需要类似Maven的工具.Maven maven正在解决的问题(自动依赖解析,基于约定的构建结构......)似乎在.NET中并不那么重要.
我的看法是否正确？
为什么会这样？
人们在.NET中真正使用的是什么？根本没有自动依赖解决方案？
他们在编写自己的构建工具吗？
是否有人使用Maven来管理他们的.NET项目？这是一个不错的选择吗？
你有什么经历？
kro*_*old 23
Maven正在被apache项目推动,这是巨大的 Java开源基础架构的核心部分.maven的广泛采用必须与此相关,目前的成熟度(质量)也非常好.
我不认为.NET开源世界有任何非常大的开源参与者来推动这样一个概念.不知怎的,.NET似乎总是等待redmond来做这些事情.
Tin*_*nku 19
虽然问题很老,但这是我的想法.Maven不仅仅是一个构建工具,它比存储库管理,项目管理,依赖管理,构建管理等更多......
但在我看来,主要的吸引力是依赖管理.JAR地狱从一开始就是Java Land中的一个大问题,你需要一些工具来应对它.在.Net世界中没有这样的问题(实际上没有DLL地狱被宣传为.Net的最初几天的主要吸引力)所以大多数人都对MSBuild很好.后来由于许多第三方库的可用性,存在管理问题.为了摆脱这个问题,他们现在有了Nuget.
所以简而言之,MsBuild + Nuget在.Net世界中对于大部分项目来说已经足够了,Maven对他们来说太过分了.
小智 14
我同意这里的很多答案..NET没有大量的独立IDE,您使用Visual Studio编写代码,管理依赖项等.VS中的解决方案对于MSBuild来说已经足够了,因此您可以从构建服务器中使用它.
另一方面,Java发展了许多IDE,而Java则从IDE管理外部项目.释放开发人员以使用他们选择的IDE.我最近开始从C#到Java的交叉培训,我可以告诉你maven构建概念是非常陌生的,但过了一段时间我喜欢它,更重要的是我看到repo概念为我提供了什么.
现在,VS托管依赖项如何要求您添加项目引用或对DLL的引用.添加DLL引用是有缺陷的.如何管理版本的更改,如何构建来自外部和内部源的第三方dll以及您希望从您自己的团队中包含但不作为项目参考的dll.我已经基于文件的目录结构做了很多解决方案,但是没有一个是优雅的,或者在版本更改时很好.也使分支变得困难,因为这会成为构建目录的一个考虑因素.
现在我已经使用Java和公共mavan repos,非常酷.我已经使用Python和pip安装有效地再次从公共回购中提取.最后我在VS 2015中再次使用C#做了一些东西,与Nuget的集成正是缺少的.
现在在企业环境中,公共回购并不总是可以直接访问,因此您需要企业回购.非Microsoft生态系统再次领先于此.
基本上总结Java是从一个更加开放的源环境演变而来的,在这个环境中没有使用IDE项目维护,而.NET是从管理项目的Visual Studio发展而来的,而这些不同的路径意味着repo后来将进入Visual Studio.
最后,这是我的观察,Java社区倾向于使用其他人的框架,因为Java基础库提供的更少.而.NET的人会编写更多自己的代码.java社区有一个更大的模式和实践生态系统,而.NET再次编写自己的代码或等待微软.这种情况正在发生变化,但再次表明为什么.NET在repos的需求方面落后于Java.
我们正在使用NAnt,因为没有成熟的替代方案.同时处理多个项目,我们已经解决了多个版本的库以及如何处理它们的问题.Maven主张非常有前途,但还不够成熟,无法在.NET平台上发挥作用.
我认为需求不那么明显,因为大多数.NET项目都使用Visual Studio,它自动建议/强制执行目录结构,依赖项等.这是一种误导性的"解决方案",因为依赖于这些约定的IDE限制了开发团队的灵活性,并锁定了特定的解决方案和供应商.这显然不是Java世界中的情况,因此明显需要类似Maven的工具.
| 归档时间： |
|
| 查看次数： |
45170 次 |
| 最近记录： |