我的印象是，在.NET世界中，实际上并不需要Maven类的工具。
我知道有Byldan和NMaven（它还活着吗？），但是我还没有看到使用它们的真实项目。
同样，在我从事的大多数.NET项目中，从未有人表示过需要类似Maven的工具。Maven Maven正在解决的问题（自动依赖项解析，基于约定的构建结构...）在.NET中似乎并不那么重要。
我的看法正确吗？
为什么会这样呢？
人们在.NET中真正使用的是什么？根本没有自动的依赖关系解决方案吗？
他们在编写自己的构建工具吗？
是否有人使用Maven本身来管理他们的.NET项目？这是一个好选择吗？
你有什么经验？
Answers:
Maven受到apache项目的推动，这些项目是庞大的Java开源基础结构的核心部分。Maven的广泛采用必须与此相关，并且当前的成熟度（质量）也非常好。
我认为.NET开源世界没有任何大型开源参与者来推动这种概念的发展。.NET总是以某种方式一直在等待雷德蒙德（Redmond）处理这些事情。
尽管这个问题很老，但我还是有这样的想法。Maven不仅仅是一个构建工具，它还完成了很多工作，例如存储库管理，项目管理，依赖项管理，构建管理等。
但是我认为主要的吸引力是依赖管理。从一开始，JAR地狱是Java Land中的一个大问题，您需要一些工具来解决它。在.Net世界中，没有这样的问题（实际上，在最初的.Net最初，没有DLL地狱的广告已成为主要吸引力），因此大多数人对MSBuild都感到满意。后来由于许多第三方库的可用性，出现了管理问题。为了摆脱这个问题，他们现在有了Nuget。
简而言之，对于大多数项目，MsBuild + Nuget在.Net世界中已经足够好，对于他们来说，Maven实在是太过分了。
我同意这里的许多答案。.NET没有大量独立的IDE，您使用Visual Studio编写代码，管理依赖项等。VS中的解决方案对于MSBuild来说已经足够好，因此您可以在构建服务器中使用它。
另一方面，Java演变了许多IDE，而Java走上了管理IDE外部项目的路线。使开发人员可以选择使用自己的IDE。我最近开始从C＃到Java进行交叉培训，我可以告诉您maven构建概念是非常陌生的，但是过了一会儿我喜欢它，更重要的是，我看到了repo概念为我提供了什么。
现在，VS受管依赖项的方式要求您添加项目引用或对DLL的引用。DLL参考的添加存在缺陷。您如何管理版本更改，如何从外部和内部资源以及您希望从自己的团队中获取的dll来构建第三方的dll，但不能作为项目参考。我通常基于基于文件的目录结构完成了许多变通方法，但是它们都不是优雅的，或者在版本更改时效果不佳。也使分支变得困难，因为这成为了如何构造目录的考虑因素。
现在，我已经使用过Java和public mavan repos，非常酷。我已经使用Python和pip再次有效地安装了公共仓库。最后，我再次使用VS 2015在C＃中做了一些工作，而与Nuget的集成正是所缺少的。
现在，在公司环境中，公共存储库并不总是可以直接访问，因此您需要公司存储库。同样，非Microsoft生态系统在此方面遥遥领先。
基本上，Java是从不使用IDE项目维护的更加开放的源代码环境演变而来的，而.NET是从管理项目的Visual Studio演变而来的，这些不同的路径意味着回购协议随后会出现在Visual Studio中。
最后，这是我的观察，由于Java基础库提供的资源较少，因此Java社区倾向于更多地使用其他人的框架。.NET人们编写了更多自己的代码。Java社区拥有更大的模式和实践生态系统，而.NET再次编写了自己的代码或等待Microsoft。这种情况正在发生变化，但再次表明为什么.NET在回购需求中落后于Java。
我们之所以使用NAnt，是因为没有真正成熟的替代方案。同时处理多个项目，我们一直在努力拥有多种版本的库以及如何处理它们。Maven的建议确实很有希望，但还不够成熟，无法在.NET平台上使用。
我认为需求不太明显，因为大多数.NET项目都使用Visual Studio，Visual Studio会自动建议/强制执行目录结构，依赖项等。这是一种误导性的“解决方案”，因为依赖于IDE的此类约定会限制开发团队的灵活性，并使您无法使用特定的解决方案和供应商。在Java世界中显然不是这种情况，因此显然需要Maven类工具。
我不喜欢基于XML的构建工具。
我们采用了ruby rake来构建.net产品。Albacore是一个非常不错的rake任务套件，用于构建.net项目。
Rake使创建复杂的构建脚本变得非常容易，并且您正在处理代码而不是大量的尖括号。
我知道这是一个旧帖子，但是当我遇到它时，我想分享其他很棒的选择。
Build Automation with PowerShell and Psake
很多人没有利用Psake（发音为sockey）的真正好处是它正在使用msbuild。
尽管这不是Maven问题的答案（Maven是出于对基于冗长冗长的ANT脚本的Java构建的需求）。
大多数人没有使用任何CI（持续集成），例如Jenkins，Hudson，Cruise Control，TeamCity，TFS，也没有使用Powershell。
利用msbuild的PSake for Powershell使事情变得任务驱动且井井有条。这是一个链接示例http://www.shilony.net/2013/06/15/build-automation-with-powershell-and-psake/
我们使用UppercuT。UppercuT使用NAnt进行构建，并且易于使用。
对于大多数项目，自动构建就像（1）解决方案名称，（2）源控制路径，（3）公司名称一样简单！
https://github.com/chucknorris/uppercut/
这里有一些很好的解释：UppercuT
UppercuT是常规的自动构建，这意味着您可以设置配置文件，然后免费获得许多功能。可以说，最强大的功能是能够在一个位置指定环境设置，并将其应用到任何地方，包括在构建源时提供的文档。
可用文档：https : //github.com/chucknorris/uppercut/wiki
特征 ：