Best IT Recipes

Why is there no need for Maven in .NET?

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

I know there are Byldan and NMaven (is he still alive?), But I have not seen the real one that uses them.

Also in most of the .NET projects I have been working on, there has never been a need for a Maven-like tool. The problems that Maven maven handles (automatic dependency detection, building a framework based on conventions ...) seem to be less important in .NET.

Is my perception correct?

Why is this so?

What do people really use in .NET? No automatic dependency resolution at all?

Do they write their own build tools?

Does anyone use Maven on their own to manage their .NET projects? It's a good choice?

What are your impressions?

+57
maven-2 build-process build-automation build
Apr 08 '09 at 11:17
source share
8 answers

To resolve artifact dependencies, I would say that Nuget is now the preferred alternative. It supports and supports build time resolution, that is, there is no need to check binary dependency artifacts on vcs. See these articles .

Starting with version 2.7 of Nuget, temporary build resolution has even better support with the Nuget restore command, which is one of the parameters.

Update: Currently there is an alternative affordable package manager with nuget support - Paket , which is better than the vanilla nuget client in handling time dependencies and harmonizing dependencies between projects in one solution. The toolkit is also quite mature (integration of VS and command line tool for CI)

+31
Mar 11 '11 at 9:40
source share

Maven is being pushed by apache projects, which are a core part of the vast open source Java infrastructure. Widespread adoption of maven should be associated with this, and the current level of maturity (quality) is also very good.

I do not think that the open source world. NET has significant open source supporters to promote such a concept. Somehow .NET always seems to be waiting for redmond for these things.

+21
Apr 08 '09 at 11:34
source share

Although the question is old, here are my thoughts. Maven is not just a build tool, it is much more than repository management, project management, dependency management, build management, etc ...

But the main attraction, in my opinion, is dependency management. JAR hell is a big problem in Java Land from the start, and you need some tools to handle this. There is no such problem in the .Net world (in fact, the absence of a DLL add-on was declared as the main attraction in the early days of .Net), so most people do a great job with MSBuild. Later, due to the presence of a large number of third-party libraries, there were problems with management. To get rid of this problem, they now have Nuget.

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

+12
Mar 24 '13 at 5:05
source share

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

Java, on the other hand, has developed many IDEs, and Java has taken the path of managing projects external to the IDE. Exempting a developer from using their IDE. I recently started cross-training with C # in Java, and I can tell you that the concept of building maven is pretty alien, but then after a while I like it, and more importantly, I see what the repo concept offers.

Now, as VS managed dependencies require you to add a link to a project or a link to a DLL. This adding a link to a DLL is erroneous. How do you manage versioning, how do you structure third-party DLL files from external and internal sources, as well as DLLs that you would like to include from your own team, but not as a link to the project. I did a lot of workarounds, based mainly on the file structure of the directories, but none of them are elegant or great when the versions change. Also makes branching difficult because it becomes a consideration in how you structure directories.

Now I have been working with Java and the mavan public repositories, super cool. I worked with Python, and pip install was effectively pulled out of public repositories again. Finally, I did some things again in C # with VS 2015, and integrating with Nuget is exactly what was missing.

Now in a corporate environment, public repositories are not always directly accessible, so you need corporate repositories. Again, non-Microsoft ecosystems are ahead.

Basically, Java summarization evolved from a more open source environment where IDE maintenance was not used, while .NET evolved from Visual Studio managing the project, and these different paths meant that the repo later came into Visual Studio.

Finally, and this is my observation, the Java community has a tendency to use other frameworks for people more, since Java core libraries offer less. While .NET people write a lot more than their code. The java community has a large ecosystem of patterns and practices, while .NET has written its own code again or has been waiting for Microsoft. This is changing, but again showing why .NET is behind Java in the requirement for repos.

+9
Apr 15 '16 at 2:45
source share

We use NAnt because there is no real alternative that is just as mature. While working on several projects, we worked to have several versions of libraries and how to deal with them. The Maven offer 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 offers / implements a directory structure, dependencies, etc. This is a misleading "solution" because, depending on the IDE, the flexibility of the development team is limited for these types of agreements and is blocked in the specific solution and provider. Obviously, this is not the case in the Java world, so there is a clear need for the Maven tool.

+5
Apr 08 '09 at 11:24
source share

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

Automated assembly is simple: solution name (1), (2) source code management path, (3) company name for most projects!

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

A few good explanations here: UppercuT

Additional Information



UppercuT is a regular automatic build, which means that you have configured a configuration file, and then you get a bunch of features for free. Probably the most powerful feature is the ability to specify environment settings in ONE place and apply them everywhere, including documentation when creating it.

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

Features:

+2
May 16 '09 at 18:35
source share

I do not like XML-based build tools.

We adapted the ruby ​​rake to build our .net products. Albacore is a really nice set of rake tasks for creating .net projects.

Rake makes it very easy to create even complex build scripts, and you are dealing with code instead of a ton of angle brackets.

+2
Jun 13 '11 at 19:11
source share

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

Build Automation with PowerShell and Psake

Many people do not use Psake (pronounced sockey), it is really great that it uses msbuild.

Although this is not the answer to the maven question (maven came about because of the need to create java based on the tedious detailed ANT scripts).

Most people do not use CI (continuous integration), for example, Jenkins, Hudson, Cruise Control, TeamCity, TFS and do not use powershell.

This Powershell PSake that uses msbuild makes things task-oriented and very organized. Here is an example link http://www.shilony.net/2013/06/15/build-automation-with-powershell-and-psake/

+2
Oct 28 '13 at 8:04 on
source share


More articles:


All Articles