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

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

我知道有Byldan和NMaven(它还活着吗?),但我还没有看到使用它们的现实世界的项目。

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

我的感觉是否正确?

这是为什么?

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

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

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

你有什么经验?

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

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

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

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

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

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

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

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

我同意这里的很多答案。 .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。

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

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

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

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

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

我知道这是一个旧的职位,但当我跑过去,我想分享其他伟大的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/

我们使用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

特征 :