81

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?

jbandi
  • 17,499
  • 9
  • 69
  • 81

10 Answers10

50

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)

8DH
  • 2,022
  • 23
  • 36
27

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.

krosenvold
  • 75,535
  • 32
  • 152
  • 208
  • 53
    That's because in the MS world, if you build your own tool and it's good, chances are MS will come out with one like it in a year or two and people will stop using yours. (As Joel Spolsky put it, "if you manage to write something that takes off, you may find that you were merely doing market research for Microsoft.") – Nate C-K Aug 31 '11 at 14:38
  • 5
    @NateC-K , isn't that a good thing? such a cruel world this. If ms is not doing such things, there is a sect complaining it is not doing, and when ms actually adopts proper meaningful projects and starts putting efforts and resources even then it is ridiculed, also isn't that what the community needs, proper tools reaching a wider audience, with these things the dev ecosystem will grow collectively – Srivathsa Harish Venkataramana Aug 17 '15 at 10:17
  • 10
    If an open source project has built a tool that the community needed, then no, MS building an equivalent tool to replace it is not what is needed. At worst, that is a duplication of effort that has no apparent purpose other than to ensure that MS owns everything. What is more appropriate is for MS to assign some paid developers to contribute to the open source project. Since I made my earlier comment, though, it looks like MS has made serious effort to play nicer with the open source community, which I appreciate. I hope that relationship will continue to improve in the coming years. – Nate C-K Aug 17 '15 at 16:40
  • Things have certainly changed in 2016 with regards to waiting for redmond for these things (build tools). We now have dotnet (core) on linux and Nexus 3 supports nuget. A whole new world. – Nico de Wet Oct 29 '16 at 08:47
  • I am pretty sure that they don't usually rebuild open source projects, but support them and improve them - much like Json.Net. Avalonia is another example – gilmishal Dec 10 '19 at 10:25
23

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.

Tinku
  • 1,592
  • 1
  • 15
  • 27
16

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.

Mark Channing
  • 201
  • 2
  • 5
6

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.

Kamiel Wanrooij
  • 12,164
  • 6
  • 37
  • 43
  • On the other hand, we migrated from NAnt to MSBuild, because manually managing NAnt script is a huuge pain. VS does it for you. I have a master MSBuild project file written by hand in xml editor which launches unit tests etc. and invokes another msbuild file (generated by VS) only for building the source. – Ivan G. Apr 19 '11 at 22:32
  • Looking at [the Github contributor's graph](https://github.com/nant/nant/graphs/contributors) it looks like NAnt has stagnated. Would you still recommend it? – Janus Troelsen Aug 02 '16 at 11:21
  • 1
    @JanusTroelsen I have't worked in .NET for a few years now.. I asked around and the most heard alternative is NuGet packages with Paket or simply PowerShell. – Kamiel Wanrooij Aug 05 '16 at 13:22
2

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/

Tom Stickel
  • 19,633
  • 6
  • 111
  • 113
2

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.

Zebi
  • 8,682
  • 1
  • 36
  • 42
2

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 :

ferventcoder
  • 11,952
  • 3
  • 57
  • 90
  • What makes it so easy? Does it have any key selling points over the others mentioned to make using this more compelling? – Don Vince Jun 10 '11 at 12:37
  • Derick Bailey did a roundup - http://lostechies.com/derickbailey/2010/05/10/build-tools-for-net-systems-it-s-no-longer-a-question-of-features/ – ferventcoder Jun 13 '11 at 18:44
  • What makes it easy is that it is a conventional build. You set the configuration and then just run build.bat. When new features are added to uppercut, you can upgrade within seconds. – ferventcoder Jun 13 '11 at 18:47
  • 1
    Hudson is still around, Oracle "owns" it, but the developers didn't like the way Oracle was running things and thus they created another butler name called Jenkins and essentially Jenkins has been well received and its adoption rate is pretty impressive. – Tom Stickel Oct 28 '13 at 08:08
  • I edited this post to note that UppercuT was abandoned – Janus Troelsen Aug 02 '16 at 11:17
  • Howdy, UppercuT source code moved over to GitHub, it was not abandoned. It has some activity but not much to add/change over time. Still actively used so not abandoned. – ferventcoder Aug 02 '16 at 11:55
0

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

Stanislav Trifan
  • 144
  • 10
0

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.

neonidian
  • 1,221
  • 13
  • 20