为什么.NET 中不需要 Maven？

小开

我们之所以使用 NAnt，是因为没有其他真正成熟的替代方案。同时处理多个项目，我们已经解决了库的多个版本以及如何处理它们的问题。Maven 的命题确实很有前途，但是还不够成熟，不足以在。NET 平台。

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

小开

Apache 项目是巨大 java 开放源码基础设施的核心部分，Maven 正受到这些项目的推动。Maven 的广泛采用肯定与此相关，当前的成熟度(质量)也非常好。

我不认为。NET 开源世界有任何显著的大型开源参与者来推动这样一个概念通过。无论如何。NET 似乎总是等着 Redmond 做这些事情。

小开

我们使用 UppercuT.UppercuT 使用 NAnt 来构建，而且它非常容易使用 BuildFramework。

自动生成简单如(1)解决方案名称，(2)源代码控制路径，(3)大多数项目的公司名称！

Https://github.com/chucknorris/uppercut/

这里有一些很好的解释: 上勾拳

更多信息

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

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

特点:

简单的设置
简单的升级
为构建过程 http://uppercut.pbworks.com/CustomizeUsingExtensionPoints的每个步骤定制扩展点(预置、后置和替换)
有关于集成 w/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
  - Gallio
  - XUnit
- NCover
- 不依赖
- 尼特里克
- 单元迁移分析仪
混淆视听
ILMerge
环境模板和生成(ConfigBuilder，DocBuilder，SQLBuilder，DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
打包输出以准备部署
拉上输出拉链

小开

最佳答案

对于工件依赖性解析，我认为 Nuget现在是首选的替代方案。它支持并促进构建时间解析，即不需要将二进制依赖项工件签入 vcs。参见这些。

从 Nuget 的2.7版本开始，构建时间分辨率甚至有了更好的支持，命令 Nuget 恢复就是其中之一。

更新: 现在有一个可供选择的、与 nuget 兼容的包管理器—— 帕克特，它比普通的 nuget 客户机在处理短暂依赖和协调同一解决方案中的项目之间的依赖方面更好。该工具似乎也相当成熟(用于 CI 的 VS 集成和命令行工具)

小开

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

我们改造了红宝石耙来建造我们的。净产品。长鳍金枪鱼是一套非常不错的 rake 任务来构建。净项目。

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

小开

虽然这个问题很老，但我的想法是。Maven 不仅仅是一个构建工具，它的作用远远超过了存储库管理、项目管理、依赖管理、构建管理等等。

但在我看来，主要的吸引力在于依赖管理。JAR 地狱从一开始就是 JavaLand 中的一个大问题，您需要一些工具来处理它。在。网络世界没有这样的问题(实际上没有 DLL 地狱已经作为一个主要的吸引力在最初几天的广告。所以大多数人对 MSBuild 都很满意。后来由于许多第三方库的可用性，出现了管理问题。为了解决这个问题，他们现在有了 Nuget。

所以简而言之，MsBuild + Nuget 在。对于这个项目的大部分网络世界来说，Maven 对他们来说太过了。

小开

我知道这是一篇老文章，但当我偶然看到它时，我想分享另一个伟大的替代品。

Build Automation with PowerShell and Psake

很多人并没有利用 Pake (发音为 sockey)的优势，真正酷的是它使用的是 msbuild。

虽然这不是对 maven 问题的回答(maven 出于对基于冗长乏味的 ANT 脚本的 Java 构建的需要)。

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

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

小开

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

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

现在，VS 托管依赖项要求您添加项目引用或对 DLL 的引用。添加 DLL 引用是有缺陷的。你如何管理版本的变化，你如何构建第三方 dls 形式的外部和内部来源，以及 dls 你想包括从你自己的团队，但不作为一个项目参考。我已经做了很多基于基于文件的目录结构的变通方案，但是没有一个是优雅的，或者当版本发生变化时非常好的。这也使得分支变得困难，因为这成为了构造目录的一个考虑因素。

现在我已经与 Java 和公共马万回购工作，超级酷。我曾与 Python 和 pip 安装有效地再次拉从公开回购。最后，我在 C # 中用 VS 2015再次做了一些工作，与 Nuget 的集成正是我所缺少的。

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

基本上总结了 Java 是从一个更加开放的源代码环境发展而来的，在这个环境中，IDE 项目维护不被使用，而。NET 是从 VisualStudio 管理项目演变而来的，这些不同的路径意味着回购将在随后的 VisualStudio 中出现。

最后，这也是我的观察结果，Java 社区倾向于更多地使用其他人的框架，因为 Java 基础库提供的框架更少。然而。NET 用户编写更多自己的代码。Java 社区有一个更大的模式和实践生态系统，而。NET 再次编写自己的代码或等待微软。这种情况正在发生变化，但这再次说明了原因。NET 在回购协议的要求上落后于 Java。

小开

这个看起来很旧，而且还是最新的。在过去的几年里，很少有人尝试不同的解决方案，比如 NMaven、 Nant 等等... ... 而且每次在一个新项目中，我都不得不调查相同的问题并重新访问这些工具。最近。NET 核心的情况变得好一点，但是它缺乏很多的功能和可用性，所提供的 maven 和 gradle。

因此，我发现目前最可行的方法是结合使用 dotnet工具和 make。下面是与 dotnet和 docker-compose协同工作的 Makefile内容示例:

.ALL: all


all: specs down


clean: down


restore: clean
dotnet restore
    

build: restore
dotnet build


test: build
dotnet test ./Backend.UnitTests
    

up:
docker-compose up --build -V -d
    

down:
docker-compose down -v --remove-orphans
    

specs: test up
dotnet test ./Backend.Specs

所以默认情况下，只要输入 make就可以运行所有程序，在特定的阶段使用 make <phase name>，比如 make test

小开

Cake 是一个很好的替代工具，其中 c # 可以用作 DSL，目前正由。NET 基金会。请参阅开始吧了解如何使用此工具。