C# Project Management with Maven

Maven is language agnostic and it should be possible to use it with other languages than Java, including C#. For example, the Maven Compiler Plugin can be configured to use the csharp compiler. There is also a .NET Maven plugin and there was a maven-csharp on javaforge.com (seems dead).

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).

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.

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.

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 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.

For .NET Core, you can use the dotnet-maven-plugin which drives the dotnet and nuget commands, as well as adds support for e.g. cleaning, releasing etc. in the "Maven way".

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).

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.