Why is there no need for Maven in .NET?

I have the impression, that in the .NET-world, there is no real need for a Maven-like tool.

I am aware that there is Byldan and NMaven (is it still alive?), but I have not yet seen a real-world project that uses them.

Also in most .NET projects I have worked on, there never was voiced an need for a Maven-like tool. The problems Maven maven is addressing (automatic dependency-resolution, conventions based build structure ...) seem not to be so important in .NET.

Is my perception correct?

Why is this the case?

What are people really using in .NET? No automatic dependency resolution at all?

Are they writing their own build tools?

Is anybody using Maven itself, to manage their .NET projects? Is this a good choice?

What are your experiences?

For artifact dependency resolving, I'd say Nuget is now the preferred alternative. It supports and promotes build time resolution, i.e. no need to check in binary dependency artifacts into vcs. See these articles.

From version 2.7 of Nuget, build time resolution has even better support with the command Nuget restore being one of the options.

Update: There is now an alternative, nuget compatible package manager available - Paket that is better than the vanilla nuget client at handling transient dependencies and harmonising dependencies between projects in the same solution. The tooling seems to be pretty mature as well (VS integration and command line tooling for CI)

Maven is being pushed by apache projects, which are a core part of the huge java open source infrastructure. The widespread adoption of maven must be related to this, and the current level of maturity (quality) is also very good.

I don't think the .NET open source world has any significantly big open source actors to push such a concept through. Somehow .NET always seems to wait for redmond for these things.

Although the question is old here are my thoughts . Maven is not simply a build tool, It does a lot more than that like repository management, project management, dependency management, build management and so on...

But the main attraction in my opinion is dependency management. JAR hell is a big problem in the Java Land right from beginning and you need some tooling to cope with it. In the .Net world there is no problem like that (actually absence of DLL hell had been advertised as a major attraction in initial days of .Net) so most of the people are fine with MSBuild. Later on due to availability of lots of third party libraries, there were management problems. To get rid of this problem they now have Nuget.

So In brief, MsBuild + Nuget is good enough in .Net world for most of the project , Maven is just overkill for them.

I agree with a lot of the answers on here. .NET did not have a large number of independent IDEs, you used Visual Studio to write your code, manage your dependencies etc. The solution in VS is good enough for MSBuild so that is what you use from your build servers.

Java on the other hand evolved many IDEs and Java went down a route of managing projects external from the IDE. Freeing the developer to use their IDE of choice. I have recently started cross training from C# into Java and I can tell you the maven build concept is quite alien, but then after a while I love it, and more importantly I see what the repo concept offers me.

Now how VS managed dependencies requires you to add either a project reference or a reference to a DLL. This adding of a DLL reference is flawed. How do you manage change of versions, how do you structure 3rd party dlls form external and internal sources as well as dlls you would like to include from your own team but not as a project reference. I have done many work-arounds based in general on file based directory structure but none of them are elegant, or great when versions changes. Also makes branching difficult because that becomes a consideration in how you structure the directories.

Now I have worked with Java and public mavan repos, super cool. I have worked with Python and pip install effectively again pulling in from public repos. Finally I did some stuff in C# again with VS 2015 and the integration with Nuget is exactly what was missing.

Now in the corporate environment public repos are not always directly accessible so you need corporate repos. Again non Microsoft ecosystems are ahead on this.

Basically summing up Java evolved from a more open source environment where the IDE project maintenance was not used whereas .NET evolved from Visual Studio managing the project, and these different paths meant that repo's are later coming in Visual Studio.

Finally and this is my observation, the Java community tends to use other people's frameworks more since the Java base libraries offers less. Whereas .NET people write a lot more of their own code. The java community has a bigger ecosystem of patterns and practices, whereas .NET again wrote own code or waited for Microsoft. This is changing but again shows why .NET is behind Java in the the requirement for repos.

We are using NAnt because there is no real alternative that is as mature. Working on multiple projects at the same time, we have worked around having multiple versions of libraries and how to deal with them. The Maven proposition is really promising, but not mature enough to be useful on the .NET platform.

I think the need is less obvious since most .NET projects use Visual Studio, which automatically suggests/enforces a directory structure, dependencies, etcetera. This is a misleading 'solution', since depending on an IDE for these kinds of conventions limit flexibility of the development team, and lock you in a specific solution and vendor. This is obviously not the case in the Java world, hence the clear need for a Maven like tool.

We use UppercuT. UppercuT uses NAnt to build and it is the insanely easy to use Build Framework.

Automated Builds as easy as (1) solution name, (2) source control path, (3) company name for most projects!

https://github.com/chucknorris/uppercut/

Some good explanations here: UppercuT

More information

---

UppercuT is a conventional automated build, which means you set up a config file and then you get a bunch of features for free. Arguably the most powerful feature is the ability to specify environment settings in ONE place and have them applied everywhere, including documentation when it builds the source.

Documentation available: https://github.com/chucknorris/uppercut/wiki

Features :

• Simple setup
• Simple upgrades
• Custom extension points (pre, post, and replace) for each step of the build process http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
• Has documentation for integration w/Team City, CruiseControl.NET, and Jenkins (formerly Hudson) https://github.com/chucknorris/uppercut/tree/master/docs
• Works on Linux w/Mono
• Versioning DLLs based on build number and source control revisions (SVN, TFS, Git, HG)
• Compile activities - F5 or Ctrl + Shift + B
• Strong naming made as easy as true/false
• Code Testing and Analysis
  • Testing
    • NUnit
    • MbUnit v2
    • Gallio
    • xUnit
  • NCover
  • NDepend
  • Nitriq
  • Mono Migration Analyzer
• Obfuscation
• ILMerge
• Environment Templating and Building (ConfigBuilder, DocBuilder, SQLBuilder, DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
• Packaging output to prepare for deployment
• Zips up output

I don't like XML based build tools.

We adapted ruby rake to build our .net products. Albacore is a really nice suite of rake tasks to build .net projects.

Rake makes it really easy to create even complex build scripts and you are dealing with code instead of tons of angle brackets.

I know this is an old post but when I ran across it, I wanted to share other great alternative.

Build Automation with PowerShell and Psake  

A lot of people are not taking advantage of Psake (pronounced sockey) the really cool thing is that it is using msbuild.

While this is not an answer to the maven question (maven came out of a need for java builds based on the tedious verbose ANT scripts).

Most people are not using any CI (continuous integration) like Jenkins, Hudson, Cruise Control, TeamCity, TFS and not using powershell either.

This PSake for Powershell that leverages msbuild makes for things to be task driven and very organized. Here is a link example http://www.shilony.net/2013/06/15/build-automation-with-powershell-and-psake/

This looks quite old one, and still up to date. During last few years was few attempts with different solutions like NMaven, Nant and so on... and each time for a new project I had to investigate the same question and revisit those tools. Lately with .NET Core the situation became little better, however it lacks much of the functionality and usability that maven and gradle provides.

So the most workable approach that I found for now is to use dotnet tool in combination with make. Find below a sample of Makefile content that works with dotnet and docker-compose alltogheter:

.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

so to run everything by default just type make and for a specific phase use make <phase name> like make test

Cake is a good alternative tool where c# can be used as the DSL and is actively being developed by .NET foundation. See Getting started on how you can use this tool.