为什么 .NET 中不需要 Maven？

Why is there no need for Maven in .NET?

提问by jbandi

I have the impression, that in the .NET-world, there is no real need for a Maven-like tool.

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

I am aware that there is Byldanand NMaven (is it still alive?), but I have not yet seen a real-world project that uses them.

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

Also in most .NET projects I have worked on, there never was voiced an need for a Maven-like tool. The problems Maven maven is addressing (automatic dependency-resolution, conventions based build structure ...) seem not to be so important in .NET.

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

Is my perception correct?

我的认知正确吗？

Why is this the case?

为什么会这样？

What are people really using in .NET? No automatic dependency resolution at all?

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

Are they writing their own build tools?

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

Is anybody using Maven itself, to manage their .NET projects? Is this a good choice?

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

What are your experiences?

你有什么经验？

采纳答案by 8DH

For artifact dependency resolving, I'd say Nugetis now the preferred alternative. It supports and promotes build time resolution, i.e. no need to check in binary dependency artifacts into vcs. See thesearticles.

对于工件依赖性解析，我认为Nuget现在是首选替代方案。它支持并促进构建时间分辨率，即无需将二进制依赖项工件检入到 vcs 中。请参阅这些文章。

From version 2.7 of Nuget, build time resolution has even better support with the command Nuget restore being one of the options.

从 Nuget 2.7 版开始，构建时间解析得到了更好的支持，其中 Nuget restore 命令是其中的选项之一。

Update:There is now an alternative, nuget compatible package manager available - Paketthat is better than the vanilla nuget client at handling transient dependencies and harmonising dependencies between projects in the same solution. The tooling seems to be pretty mature as well (VS integration and command line tooling for CI)

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

回答by krosenvold

Maven is being pushed by apache projects, which are a core part of the hugejava open source infrastructure. The widespread adoption of maven must be related to this, and the current level of maturity (quality) is also very good.

Maven 由 apache 项目推动，Apache 项目是庞大的Java 开源基础设施的核心部分。maven的广泛采用肯定与此有关，目前的成熟度（质量）也很好。

I don't think the .NET open source world has any significantly big open source actors to push such a concept through. Somehow .NET always seems to wait for redmond for these things.

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

回答by Tinku

Although the question is old here are my thoughts . Maven is not simply a build tool, It does a lot more than that like repository management, project management, dependency management, build management and so on...

虽然这个问题很老，但这里是我的想法。Maven 不仅仅是一个构建工具，它的功能远不止这些，比如存储库管理、项目管理、依赖项管理、构建管理等等……

But the main attraction in my opinion is dependency management. JAR hell is a big problem in the Java Land right from beginning and you need some tooling to cope with it. In the .Net world there is no problem like that (actually absence of DLL hell had been advertised as a major attraction in initial days of .Net) so most of the people are fine with MSBuild. Later on due to availability of lots of third party libraries, there were management problems. To get rid of this problem they now have Nuget.

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

So In brief, MsBuild + Nuget is good enough in .Net world for most of the project , Maven is just overkill for them.

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

回答by Mark Channing

I agree with a lot of the answers on here. .NET did not have a large number of independent IDEs, you used Visual Studio to write your code, manage your dependencies etc. The solution in VS is good enough for MSBuild so that is what you use from your build servers.

我同意这里的很多答案。.NET 没有大量独立的 IDE，您使用 Visual Studio 编写代码、管理依赖项等。VS 中的解决方案对于 MSBuild 来说已经足够好了，因此您可以从构建服务器使用它。

Java on the other hand evolved many IDEs and Java went down a route of managing projects external from the IDE. Freeing the developer to use their IDE of choice. I have recently started cross training from C# into Java and I can tell you the maven build concept is quite alien, but then after a while I love it, and more importantly I see what the repo concept offers me.

另一方面，Java 发展了许多 IDE，而 Java 则走上了从 IDE 管理外部项目的道路。使开发人员可以使用他们选择的 IDE。我最近开始从 C# 到 Java 的交叉培训，我可以告诉你 maven 构建概念非常陌生，但过了一段时间我喜欢它，更重要的是我看到了 repo 概念为我提供了什么。

Now how VS managed dependencies requires you to add either a project reference or a reference to a DLL. This adding of a DLL reference is flawed. How do you manage change of versions, how do you structure 3rd party dlls form external and internal sources as well as dlls you would like to include from your own team but not as a project reference. I have done many work-arounds based in general on file based directory structure but none of them are elegant, or great when versions changes. Also makes branching difficult because that becomes a consideration in how you structure the directories.

现在 VS 托管依赖项如何要求您添加项目引用或对 DLL 的引用。添加 DLL 引用是有缺陷的。您如何管理版本更改，如何构建来自外部和内部源的 3rd 方 dll 以及您希望从您自己的团队中包含但不作为项目参考的 dll。我已经做了很多基于文件目录结构的变通方法，但没有一个是优雅的，或者在版本更改时很好。也使分支变得困难，因为这成为您如何构建目录的一个考虑因素。

Now I have worked with Java and public mavan repos, super cool. I have worked with Python and pip install effectively again pulling in from public repos. Finally I did some stuff in C# again with VS 2015 and the integration with Nuget is exactly what was missing.

现在我已经使用了 Java 和公共 mavan 存储库，超级酷。我已经使用 Python 和 pip install 再次有效地从公共存储库中提取。最后，我再次使用 VS 2015 在 C# 中做了一些事情，而与 Nuget 的集成正是所缺少的。

Now in the corporate environment public repos are not always directly accessible so you need corporate repos. Again non Microsoft ecosystems are ahead on this.

现在，在企业环境中，公共存储库并不总是可以直接访问的，因此您需要企业存储库。在这方面，非微软生态系统再次领先。

Basically summing up Java evolved from a more open source environment where the IDE project maintenance was not used whereas .NET evolved from Visual Studio managing the project, and these different paths meant that repo's are later coming in Visual Studio.

基本上总结 Java 是从更开放的源代码环境演变而来的，其中不使用 IDE 项目维护，而 .NET 从 Visual Studio 管理项目演变而来，这些不同的路径意味着 repo 稍后会出现在 Visual Studio 中。

Finally and this is my observation, the Java community tends to use other people's frameworks more since the Java base libraries offers less. Whereas .NET people write a lot more of their own code. The java community has a bigger ecosystem of patterns and practices, whereas .NET again wrote own code or waited for Microsoft. This is changing but again shows why .NET is behind Java in the the requirement for repos.

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

回答by Kamiel Wanrooij

We are using NAnt because there is no real alternative that is as mature. Working on multiple projects at the same time, we have worked around having multiple versions of libraries and how to deal with them. The Maven proposition is really promising, but not mature enough to be useful on the .NET platform.

我们使用 NAnt 是因为没有真正成熟的替代方案。同时处理多个项目，我们一直在处理多个版本的库以及如何处理它们。Maven 提议确实很有前途，但还不够成熟，无法在 .NET 平台上使用。

I think the need is less obvious since most .NET projects use Visual Studio, which automatically suggests/enforces a directory structure, dependencies, etcetera. This is a misleading 'solution', since depending on an IDE for these kinds of conventions limit flexibility of the development team, and lock you in a specific solution and vendor. This is obviously not the case in the Java world, hence the clear need for a Maven like tool.

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

回答by ferventcoder

We use UppercuT. UppercuT uses NAnt to build and it is the insanely easy to use Build Framework.

我们使用UppercuT。UppercuT 使用 NAnt 构建，它是非常容易使用的构建框架。

Automated Builds as easy as (1) solution name, (2) source control path, (3) company name for most projects!

自动化构建就像 (1) 解决方案名称、(2) 源代码控制路径、(3) 大多数项目的公司名称一样简单！

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

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

Some good explanations here: UppercuT

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

More information

更多信息

---

---

UppercuT is a conventional automated build, which means you set up a config file and then you get a bunch of features for free. Arguably the most powerful feature is the ability to specify environment settings in ONE place and have them applied everywhere, including documentation when it builds the source.

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

Documentation available: https://github.com/chucknorris/uppercut/wiki

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

Features :

特征 ：

• Simple setup
• Simple upgrades
• Custom extension points (pre, post, and replace) for each step of the build process http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
• Has documentation for integration w/Team City, CruiseControl.NET, and Jenkins (formerly Hudson) https://github.com/chucknorris/uppercut/tree/master/docs
• Works on Linux w/Mono
• Versioning DLLs based on build number and source control revisions (SVN, TFS, Git, HG)
• Compile activities - F5 or Ctrl + Shift + B
• Strong naming made as easy as true/false
• Code Testing and Analysis
  • Testing
    • NUnit
    • MbUnit v2
    • Gallio
    • xUnit
  • NCover
  • NDepend
  • Nitriq
  • Mono Migration Analyzer
• Obfuscation
• ILMerge
• Environment Templating and Building (ConfigBuilder, DocBuilder, SQLBuilder, DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
• Packaging output to prepare for deployment
• Zips up output

• 简单的设置
• 简单的升级
• 构建过程中每个步骤的自定义扩展点（前、后和替换）http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
• 有与 Team City、CruiseControl.NET 和 Jenkins（以前的 Hudson）集成的文档https://github.com/chucknorris/uppercut/tree/master/docs
• 在带有 Mono 的 Linux 上工作
• 基于内部版本号和源代码控制修订版（SVN、TFS、Git、HG）对 DLL 进行版本控制
• 编译活动 - F5 或 Ctrl + Shift + B
• 强命名就像真/假一样简单
• 代码测试与分析
  • 测试
    • 单位
    • MbUnit v2
    • 加里奥
    • 单位
  • 封面
  • 依赖
  • 硝基
  • Mono 迁移分析器
• 混淆
• 合并
• 环境模板和构建（ConfigBuilder、DocBuilder、SQLBuilder、DeploymentBuilder）https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
• 打包输出以准备部署
• 压缩输出

回答by Tom Stickel

I know this is an old post but when I ran across it, I wanted to share other great alternative.

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

Build Automation with PowerShell and Psake  

A lot of people are not taking advantage of Psake (pronounced sockey) the really cool thing is that it is using msbuild.

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

While this is not an answer to the maven question (maven came out of a need for java builds based on the tedious verbose ANT scripts).

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

Most people are not using any CI (continuous integration) like Jenkins, Hudson, Cruise Control, TeamCity, TFS and not using powershell either.

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

This PSake for Powershell that leverages msbuild makes for things to be task driven and very organized. Here is a link example http://www.shilony.net/2013/06/15/build-automation-with-powershell-and-psake/

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

回答by Zebi

I don't like XML based build tools.

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

We adapted ruby rake to build our .net products. Albacoreis a really nice suite of rake tasks to build .net projects.

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

Rake makes it really easy to create even complex build scripts and you are dealing with code instead of tons of angle brackets.

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