为什么在.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
特征 :
- 简单的设置
- 简单的升级
- 为构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
- 单一迁移分析器
- testing
- 困惑
- ILMerge
- 环境模板和构build(ConfigBuilder,DocBuilder,SQLBuilder,DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
- 打包输出以准备部署
- 压缩输出