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?

Solution 1:

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)

Solution 2:

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.

Solution 3:

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.

Solution 4:

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.