使用 Maven 进行 C# 项目管理
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2281052/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
C# Project Management with Maven
提问by Roman
Anyone had experience of managing C# based projects with Maven?
任何人都有使用 Maven 管理基于 C# 的项目的经验？
If yes , please tell me a few words about it , how weird would it be to create such a setup.
如果是，请告诉我几句话，创建这样的设置会有多奇怪。
Thanks
谢谢
采纳答案by Pascal Thivent
Maven is language agnostic and it should be possible to use it with other languages than Java, including C#. For example, the Maven Compiler Plugincan be configured to use the csharpcompiler. There is also a .NET Maven pluginand there was a maven-csharpon javaforge.com (seems dead).
Maven 与语言无关，它应该可以与 Java 以外的其他语言一起使用，包括 C#。例如，Maven Compiler Plugin可以配置为使用csharp编译器。还有一个.NET Maven 插件，javaforge.com 上有一个maven-csharp（似乎已经死了）。
But Java is getting most attention and man power and there is not much done with other languages. So, while using Maven with C# is in theory possible, I wouldn't expect much support and feedback from the community (i.e. in case of problem, you'll be alone). I don't know if using Maven for C# would thus be a good idea. I wouldn't recommend it actually (I may be wrong of course).
但是 Java 获得了最多的关注和人力，其他语言没有做太多。因此，虽然理论上可以将 Maven 与 C# 一起使用，但我不希望社区提供太多支持和反馈（即，如果出现问题，您将独自一人）。我不知道将 Maven 用于 C# 是否是一个好主意。我实际上不会推荐它（当然我可能是错的）。
回答by Wim Coenen
There is a NMavenproject at codeplex but it doesn't seem to be active or popular. See also these questions:
codeplex有一个NMaven项目，但它似乎并不活跃或流行。另请参阅以下问题：
- maven for .NET(DroidIn.net's link to his tutoriallooks promising)
- Why is there no need for maven in .NET
- Is there a Maven Alternative or port for the .NET world?
回答by Brett Porter
You might also check out NPanday(it is a project I am involved in). While it still needs some work to more closely align to Maven's best practices, it is the most complete and active alternative available now. One feature that is unique to it is the existence of a Visual Studio Add-in for generating the correct pom.xmlfrom the IDE.
您也可以查看Npanday（这是我参与的一个项目）。虽然它仍然需要一些工作来更紧密地与 Maven 的最佳实践保持一致，但它是目前可用的最完整和最活跃的替代方案。它独有的一项功能是存在用于pom.xml从 IDE生成正确数据的 Visual Studio 加载项。
回答by mcating
I work with a suite of C# and C++ components and applications that are dependency-managed via maven. The general rule of "If it can be done via command-line, it can be done in maven" holds, so we end up having a lot of .bat, .exe and powershell "glue" to get all the pieces playing together.
我使用一套通过 maven 进行依赖管理的 C# 和 C++ 组件和应用程序。“如果它可以通过命令行完成，它可以在 maven 中完成”的一般规则成立，所以我们最终有很多 .bat、.exe 和 powershell“胶水”来让所有的部分一起玩。
The biggest problem with using maven for a Microsoft stack is a complete lack of familiarity with the build/deployment/ALM cycle for ANY new developer. You can find many developers with MSBuild, TFSBuild, ANT, etc., experience, but it's a rare thing to find a C# or C++ dev who's worked with maven in a pure Microsoft shop. The rollout of maven for dependency management and build process is consequently extremely difficult, since you end up spending a LOT of time training developers (what's the difference between a snapshot and a release?), over-componentizing the product then scaling it back to get it right, etc.
将 maven 用于 Microsoft 堆栈的最大问题是完全不熟悉任何新开发人员的构建/部署/ALM 周期。你可以找到很多具有 MSBuild、TFSBuild、ANT 等经验的开发人员，但在纯微软商店中找到使用 maven 的 C# 或 C++ 开发人员是很少见的。因此，推出用于依赖管理和构建过程的 maven 非常困难，因为您最终要花费大量时间培训开发人员（快照和发布之间有什么区别？），过度组件化产品然后将其缩小以获得它是对的，等等。
I've also found that we've had to work around maven to do something resembling continuous integration and continuous delivery. About 70% of our technology stack is C# (the rest being C++), and we want to deploy most of that to QA servers every single night with the latest-and-greatest code by default. To balance the value of release builds vs. dev productivity via snapshots, we ended up constructing a build process where we create a release build of every component each night, followed by a snapshot build. This let the developers not have to worry about bumping POMs to consume snapshots in the morning. Overall, it's a royal pain, at least for someone coming from robust continuous integration, "build and deploy everything" environments.
我还发现我们不得不围绕 maven 做一些类似于持续集成和持续交付的工作。我们大约 70% 的技术堆栈是 C#（其余的是 C++），我们希望每晚都将其中的大部分部署到 QA 服务器，默认情况下使用最新最好的代码。为了通过快照平衡发布版本与开发生产力的价值，我们最终构建了一个构建过程，我们每晚创建每个组件的发布版本，然后是快照构建。这让开发人员不必担心在早上撞到 POM 来消耗快照。总的来说，这是一个巨大的痛苦，至少对于来自强大的持续集成、“构建和部署一切”环境的人来说。
Maven holds a lot of promise for dependency management and isolating breaking changes (particularly in interface components where the consumer and producer have to agree). Those problems have been solved other ways (svn externs, deployment builds, interface version management, etc.). But it is relatively nice to download any component, run "mvn compile", and see the code compile (assuming a basic level of build portability). For me, though, the overhead and the meta-conversations about getting the build right (as opposed to focusing on customer value) minimize the value of maven overall.
Maven 在依赖管理和隔离破坏性更改（特别是在消费者和生产者必须同意的接口组件中）方面有很多承诺。这些问题已通过其他方式解决（svn externs、部署构建、接口版本管理等）。但是下载任何组件，运行“mvn compile”，并查看代码编译（假设构建可移植性的基本级别）相对较好。然而，对我来说，关于正确构建（而不是关注客户价值）的开销和元对话使 maven 的整体价值最小化。
回答by Gabriel Go?c
maven-compiler-plugin with plexus-compiler-csharp works just fine with the following configuration. Of course you'll have to point to an actual C# compiler on your machine with the "executable" parameter.
带有 plexus-compiler-csharp 的 maven-compiler-plugin 在以下配置下工作得很好。当然，您必须使用“可执行文件”参数指向计算机上的实际 C# 编译器。
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.0</version>
<configuration>
<compilerId>csharp</compilerId>
<fork>true</fork>
<executable>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe</executable>
<outputFileName>myDLL</outputFileName>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-compiler-csharp</artifactId>
<version>2.2</version>
</dependency>
</dependencies>
</plugin>
回答by Kasper S?rensen
For .NET Core, you can use the dotnet-maven-pluginwhich drives the dotnetand nugetcommands, as well as adds support for e.g. cleaning, releasing etc. in the "Maven way".
对于.NET Core，您可以使用驱动和命令的dotnet-maven-plugin，dotnet并nuget以“Maven 方式”添加对例如清理、发布等的支持。
Here's an example plugin configuration:
这是一个示例插件配置：
<project>
[...]
<packaging>dotnet</packaging>
[...]
<build>
<plugins>
<plugin>
<groupId>org.eobjects.build</groupId>
<artifactId>dotnet-maven-plugin</artifactId>
<version>0.11</version>
<extensions>true</extensions>
</plugin>
</plugins>
</build>
[...]
</project>
(Notice the packaging type set to dotnet).
（注意设置为 dotnet 的打包类型）。
This will then read from the project.json file and run dotnet and nuget commands according to the maven lifecycle phases such as clean, compile, test, install etc.
然后，这将从 project.json 文件中读取并根据 Maven 生命周期阶段（例如清理、编译、测试、安装等）运行 dotnet 和 nuget 命令。
回答by rochajoel
Check this out: http://interfaceable.blogspot.com/2019/01/how-to-mavenize-visual-studio-project.html
看看这个：http: //interfaceable.blogspot.com/2019/01/how-to-mavenize-visual-studio-project.html
At the time i developed those scripts/solution i was unaware that such csharp support existed from Maven, but i do recommend using Maven for the build since it enables you to automate/orchestrate everything such as IIS + ActiveMQ + MongoDB bring-up on the pre-integration-test phase, and then we are able to run tests using vstest. Not to mention that you can integrate it with Jenkins and run your builds on a remote machine.
在我开发这些脚本/解决方案时，我不知道 Maven 存在这样的 csharp 支持，但我确实建议使用 Maven 进行构建，因为它使您能够自动化/编排所有内容，例如 IIS + ActiveMQ + MongoDB 启动预集成测试阶段，然后我们可以使用 vstest 运行测试。更不用说您可以将它与 Jenkins 集成并在远程机器上运行您的构建。
I personally recommend it, but bear in mind that you will be faced with some challenges sometimes.
我个人推荐它，但请记住，您有时会面临一些挑战。
