为什么.NET中不需要Maven？

Question

我的印象是，在.NET世界中，并不需要类似Maven的工具。

我知道有Byldan和NMaven（它还活着吗？），但我还没有看到使用它们的真实项目。

同样在我工作的大多数.NET项目中，从未有人表示需要类似Maven的工具。 Maven maven正在解决的问题（自动依赖解析，基于约定的构建结构......）似乎在.NET中并不那么重要。

我的看法是否正确？

为什么会这样？

人们在.NET中真正使用的是什么？根本没有自动依赖解决方案？

他们是在编写自己的构建工具吗？

是否有人使用Maven来管理他们的.NET项目？这是 一个不错的选择？

您有什么经历？

Answer 1

对于工件依赖性解析，我会说Nuget现在是首选替代方案。 它支持并促进构建时间解析，即无需将二进制依赖项工件检入vcs。请参阅these articles。

从Nuget的2.7版开始，构建时间解析具有更好的支持，Nuget restore命令就是其中一个选项。

<强>更新 现在有一个替代的，nuget兼容的包管理器可用 - Paket，它比vanilla nuget客户端更好地处理瞬态依赖关系并协调同一解决方案中项目之间的依赖关系。工具似乎也非常成熟（用于CI的VS集成和命令行工具）

Answer 2

Maven正在被apache项目推动，这是巨大的 java开源基础架构的核心部分。 maven的广泛采用必须与此相关，目前的成熟度（质量）也非常好。

我不认为.NET开源世界有任何非常大的开源参与者来推动这样一个概念。不知怎的，.NET似乎总是等待redmond来做这些事情。

Answer 3

虽然这个问题很老，但这是我的想法。 Maven不仅仅是一个构建工具，它比存储库管理，项目管理，依赖管理，构建管理等更多......

但我认为主要的吸引力在于依赖管理。 JAR地狱从一开始就是Java Land中的一个大问题，你需要一些工具来应对它。在.Net世界中没有这样的问题（实际上没有DLL地狱被宣传为.Net的最初几天的主要吸引力）所以大多数人都对MSBuild很好。后来由于许多第三方库的可用性，存在管理问题。为了摆脱这个问题，他们现在有了Nuget。

所以简而言之，对于大多数项目来说，MsBuild + Nuget在.Net世界中已经足够了，Maven对他们来说太过分了。

Answer 4

我同意这里的很多答案。 .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的集成正是缺少的。

现在，在企业环境中，公共回购并不总是可以直接访问，因此您需要企业回购。非微软生态系统再次领先于此。

基本上总结Java是从一个不使用IDE项目维护的更开源的环境演变而.NET从Visual Studio管理项目发展而来的，这些不同的路径意味着repo后来将进入Visual Studio 。

最后，这是我的观察，Java社区倾向于使用其他人的框架，因为Java基础库提供的更少。而.NET的人会编写更多自己的代码。 java社区有一个更大的模式和实践生态系统，而.NET再次编写自己的代码或等待微软。这种情况正在发生变化，但再次表明为什么.NET在repos的要求方面落后于Java。

Answer 5

我们正在使用NAnt，因为没有成熟的替代方案。同时处理多个项目，我们已经解决了多个版本的库以及如何处理它们的问题。 Maven主张非常有前途，但还不够成熟，无法在.NET平台上发挥作用。

我认为需求不那么明显，因为大多数.NET项目都使用Visual Studio，它自动建议/强制执行目录结构，依赖项等。这是一种误导性的“解决方案”，因为依赖于这些约定的IDE限制了开发团队的灵活性，并锁定了特定的解决方案和供应商。这显然不是Java世界的情况，因此明显需要类似Maven的工具。

Answer 6

我们使用UppercuT。 UppercuT使用NAnt构建，它是一个非常容易使用的Build Framework。

自动构建与（1）解决方案名称，（2）源控制路径，（3）大多数项目的公司名称一样简单！

https://github.com/chucknorris/uppercut/

这里有一些很好的解释：UppercuT

更多信息

---

UppercuT是一种传统的自动构建，这意味着您可以设置配置文件，然后免费获得一系列功能。可以说，最强大的功能是能够在一个地方指定环境设置并在任何地方应用它们，包括构建源代码时的文档。

可用文档：https://github.com/chucknorris/uppercut/wiki

特点：

• 简单设置
• 简单升级
• 构建过程的每个步骤的自定义扩展点（前置，后置和替换）http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
• 包含Team City，CruiseControl.NET和Jenkins（以前称为Hudson）的集成文档https://github.com/chucknorris/uppercut/tree/master/docs
• 适用于Linux w / Mono
• 基于内部版本号和源代码管理修订版（SVN，TFS，Git，HG）对DLL进行版本控制
• 编译活动 - F5或Ctrl + Shift + B
• 强有力的命名就像真/假一样简单
• 代码测试和分析
  • 测试
    • NUnit的
    • MbUnit v2
    • 加利奥
    • 的xUnit
  • NCover
  • NDepend的
  • Nitriq
  • Mono Migration Analyzer
• 模糊处理
• ILMerge
• 环境模板和构建（ConfigBuilder，DocBuilder，SQLBuilder，DeploymentBuilder）https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
• 打包输出以准备部署
• 拉出输出

Answer 7

我不喜欢基于XML的构建工具。

我们采用ruby rake来构建我们的.net产品。 Albacore是构建.net项目的一套非常好的rake任务。

Rake使得创建复杂的构建脚本变得非常容易，而且您正在处理代码而不是大量的尖括号。

Answer 8

我知道这是一个老帖子，但当我遇到它时，我想分享其他很好的选择。

Build Automation with PowerShell and Psake  

很多人没有利用Psake（发音为sockey）真正酷的是它正在使用msbuild。

虽然这不是maven问题的答案（maven出于对基于繁琐冗长的ANT脚本的java构建的需求）。

大多数人都没有使用任何CI（持续集成），如Jenkins，Hudson，Cruise Control，TeamCity，TFS，也没有使用PowerShell。

这个利用msbuild的PSers for Powershell使得事情成为任务驱动且非常有条理。这是一个链接示例http://www.shilony.net/2013/06/15/build-automation-with-powershell-and-psake/