为什么在.NET中不需要Maven？

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

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

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

我的感觉是否正确？

这是为什么？

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

他们正在编写自己的构build工具吗？

是否有人使用Maven来pipe理他们的.NET项目？ 这是一个不错的select吗？

你有什么经验？

Answer 1

为了解决工件依赖问题，我认为Nuget现在是最好的select。 它支持并促进构build时间parsing，即不需要将二进制依赖项构件检入到vcs中。 看到这些 文章 。

从Nuget 2.7版本开始，构build时间parsing甚至可以使用命令Nuget restore作为选项之一。

更新：现在有一个替代的nuget兼容的包pipe理器可用 – Paket比在同一个解决scheme中处理瞬态依赖关系和协调项目之间的依赖关系更好。 工具似乎也相当成熟（CI集成和命令行工具）

Answer 2

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

我不认为.NET开源世界有什么大的开源代码来推动这个概念。 不知何故，.NET似乎总是在等待redmond的这些东西。

Answer 3

虽然这个问题很老，但我的想法是。 Maven不是一个简单的构build工具，它比存储库pipe理，项目pipe理，依赖pipe理，构buildpipe理等等做得更多。

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

所以简而言之，在项目的大部分时间里，MsBuild + Nuget对于.Net世界来说已经足够了，Maven对他们来说只是矫枉过正。

Answer 4

我同意这里的很多答案。 .NET没有大量的独立IDE，你使用Visual Studio来编写你的代码，pipe理你的依赖关系等等。VS中的解决scheme对于MSBuild来说已经足够了，所以这就是你在构build服务器上使用的方法。

另一方面，Java演化了许多IDE，而Java则走上了pipe理IDE外部项目的路线。 释放开发人员使用他们select的IDE。 我最近开始从C＃到Java的交叉培训，我可以告诉你，Maven的构build概念是相当陌生的，但是过了一段时间，我喜欢它，更重要的是我看到了回购概念给我提供了什么。

现在，VSpipe理的依赖关系如何要求您添加项目引用或对DLL的引用。 这个DLL引用的添加是有缺陷的。 你如何pipe理版本的变化，你如何构build第三方DLLforms的外部和内部的来源，以及你想从你自己的团队，而不是作为一个项目的参考DLL。 我已经做了很多基于文件的目录结构的变通，但是没有一个是优雅的，或者当版本改变的时候，它们都是很好的。 也使分支困难，因为这成为如何构build目录的考虑因素。

现在我已经与Java和公共mavan回购，超级酷。 我已经和Python一起工作，并有效地再次从公共回购拉动pip安装。 最后我在VS 2015中再次用C＃做了一些东西，而与Nuget的集成正是缺less的东西。

现在在企业环境中，公共回购并不总是可以直接访问的，所以您需要公司回购。 非微软的生态系统也在这方面领先。

基本上总结了Java从一个更开放的源代码环境演化而来，IDE项目维护没有被使用，而.NET则是从Visual Studiopipe理项目演化而来的，而这些不同的途径意味着后面的回购将会在Visual Studio中出现。

最后，这是我的观察，Java社区往往更多地使用其他人的框架，因为Java基础库提供更less。 而.NET的人写更多的自己的代码。 Java社区拥有更大的模式和实践生态系统，而.NET再次编写自己的代码或等待微软。 这正在改变，但再次显示了为什么.NET在回购的要求背后Java。

Answer 5

我们正在使用NAnt，因为没有一个真正的select是成熟的。 在同一时间处理多个项目，我们已经有了多个版本的库以及如何处理它们。 Maven的命题是非常有前途的，但还不够成熟，在.NET平台上有用。

我认为这个需求不太明显，因为大多数.NET项目都使用Visual Studio，它会自动build议/强制执行目录结构，依赖关系等等。 这是一个误导性的“解决scheme”，因为依赖于这些约定的IDE限制了开发团队的灵活性，并将您locking在特定的解决scheme和供应商中。 这在Java世界中显然不是这样，因此明确需要一个类似Maven的工具。

Answer 6

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

我们调整ruby耙来build立我们的.net产品。 Albacore是构build.net项目的一个非常好的rake任务套件。

Rake使得创build复杂的构build脚本变得非常简单，而且您正在处理的是代码而不是尖括号。

Answer 7

我知道这是一个旧的职位，但当我跑过去，我想分享其他伟大的select。

Build Automation with PowerShell and Psake 

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

虽然这不是maven问题的答案（maven基于繁琐冗长的ANT脚本需要Java构build）。

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

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

Answer 8

我们使用UppercuT。 UppercuT使用NAnt来构build，使用Build Framework非常简单。

自动构build像（1）解决scheme名称一样简单，（2）源代码pipe理path，（3）大多数项目的公司名称！

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

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

更多信息

---

UppercuT是一个传统的自动构build，这意味着你build立一个configuration文件，然后你可以免费获得一堆function。 可以说，最强大的function是能够在一个地方指定环境设置，并将它们应用于任何地方，包括构build源代码时的文档。

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

特征 ：

• 简单的设置
• 简单的升级
• 为构build过程的每个步骤自定义扩展点（前，后，和replace） http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
• 具有Team City，CruiseControl.NET和Jenkins（以前称为Hudson）的集成文档https://github.com/chucknorris/uppercut/tree/master/docs
• 适用于带有单声道的Linux
• 基于内部版本号和源代码控制版本（SVN，TFS，Git，HG）的版本控制DLL
• 编译活动 – F5或Ctrl + Shift + B
• 强烈的命名就像真假一样简单
• 代码testing和分析
  • testing
    • NUnit的
    • MbUnit v2
    • 加利奥
    • 的xUnit
  • NCover
  • NDepend的
  • Nitriq
  • 单一迁移分析器
• 困惑
• ILMerge
• 环境模板和构build（ConfigBuilder，DocBuilder，SQLBuilder，DeploymentBuilder） https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
• 打包输出以准备部署
• 压缩输出