Is Nuget a failure?

Topics: General
Jun 30, 2014 at 5:12 AM
I might be off the mark here, and I am not out to cause upset, but my experiences of Nuget have not been good, and I want to put it out there to see if I am missing something...

When Nuget first appeared a few years ago I thought it was a great idea, and it was something which should make life easier. After the first few uses it became apparent that the VS client for it was buggy - but it was still good to use it as a single point to download plugins.

Several years on, and I still find it barely usable, and now I am wondering if it is only me, and all the members of the 2 teams I have worked in since then who are having problems with it. How can a piece of software be around for so long and still be so full of bugs? Have the developers of it ever used it in a real world scenario and felt the pain that I feel?

The thing that has prompted me to write this is that I am once again upgrading to the latest entity framework. There goes 2 days of my life - again - wrestling with Nuget while it does random things to the files on my machine and in TFS. I also made a new web project and discovered that although I thought I was downloading version x of several Microsoft downloads it was in fact supplying me with version y. I then search 'Microsoft and .NET' for the same thing and amazingly I get the right version. Then, every time I open the solution it decided it's going to download another few hundred files for no apparent reason...

The most annoying thing about this is that it is such a missed opportunity. This could have been great, but it seems to be such a royal pain in the arse that I have decided to stop using it in our production solutions. I am going back to using it just to download binaries which I will then copy where I need them. Although, having said that even this is difficult now because I now need to know that when something references, for example, System.Net.http.Formatting I need to download Microsoft.AspNet.Http.Something - or something with a completely different name - who decided to change names on all these things??

Tell me I'm wrong and that I have missed something...
Jun 30, 2014 at 6:51 AM
I agree with you.

In addition, I'll add that the community management for this project is dreadful.
I won't stop using NuGet though. A package manager is absolutely essential these days and there is no alternative.
Jul 15, 2014 at 11:55 AM
I agree too. What I know is that I am spending way too much time having to resolve version dependencies between projects within a solution.
Jul 17, 2014 at 2:31 PM
Edited Jul 17, 2014 at 2:32 PM
How would it be any different if you weren't using NuGet? I mean, how could they solve this problem? Versioning problems have been around for ages. (Dependency Hell)

I think that the real benefits of NuGet are:
  • Discoverability
  • Consistency
  • Updates (typically very easy, unless Dependency Hell creeps in)
  • IDE integration
How is NuGet a failure when it comes to the aforementioned benefits?
Jul 17, 2014 at 6:37 PM
I presume you've been a good open source advocate/user and logged bugs for all of your complaints? ;)
Jul 17, 2014 at 8:50 PM
I use to put 3rd party libraries into source code control and made the references from the projects to the libraries at the 3rd party library location. When a new version came out I'd get it and put it into source code control and changed the references in the projects. It ended up being extra work for one person, but everyone else involved with the project didn't have to do anything.

I know there is a method to the madness and it will get better, but right now it feels like an uncontrolled mess.
Jul 28, 2014 at 11:42 AM
Hi Davedev. Seems like you are happy with it... Just out of interest - what size of solutions, and number of solutions are you working with? What size of team are you in?

I find that if it is a fairly simple solution with a handful of projects in it then it's not too much of a problem. But when working with large solutions (80+ projects) and a large number of solutions, nuget seems to get confused. The best example of this is when you try to upgrade Entity Framework. The last few times I had to do this with Nuget, it took me over a day (due to issues with Nuget - nothing to do with dependency issues). After I checked in, the rest of the team members lost half a day each for the same reason. We finally gave up with Nuget and took it out of the equation, and now upgrading EF takes seconds across all solutions. It also kills TFS - the amount of pointless files which Nuget downloads for no reason is ridiculous, and it keeps downloading files for days after adding things from Nuget. I could go on about the problems we have had - to summarise, it has been the single point of pain for every team I have been in where we have tried to use it.
Jul 28, 2014 at 11:46 AM
Hi Oisin. Each time I have looked into the problems I have been experiencing I have discovered that they have already been well documented. Most of the time they have been marked as fixed - even though they weren't, or they have been fixed but you still can't do what you want because of another well documented issue. However, the thing that annoys me is that something which has been around for so long should be more stable by now - surely the people developing it must have noticed the problems?
Jul 29, 2014 at 3:41 AM
I don't think that posting "this thing sucks, doesn't it" and inviting people to agree with you is a good way to encourage improvement. While I have had occasional issues with Nuget, overall it has been extremely helpful to me in my work, and I think that it has been a fantastic addition to the .NET ecosystem.

You use a lot of vague anecdotes ("I lost two days", "it keeps downloading files for days", "it has been the single point of pain for every team I have been in"), but there is no information in your posts that would allow anyone to evaluate whether the problems you have been experiencing are actually caused by Nuget. Suffice it to say that having used Nuget for over three years, I have never experienced problems anywhere close to the scale that you describe. Maybe we are in different circumstances, or maybe I use it differently than you do. But claiming that the tool must not be stable because you are experiencing problems (in what sounds like an edge case scenario - a solution with 80+ projects??) while tens of thousands of developers use it successfully every day seems to me to be a very narrow viewpoint.

If you are actually interested in improving Nuget, then by all means post the specifics of your problems, and give others a chance to help you, and/or to find and fix any bugs in Nuget that are causing your problems. Even better, find and fix them yourself! That's the great thing about open source software, you don't have to wait for someone else to fix your problems.
Jul 29, 2014 at 5:49 AM
"I don't think that posting "this thing sucks, doesn't it" and inviting people to agree with you is a good way to encourage improvement"

Really? I would argue that it is exactly the way to encourage improvement. There is nothing worse that a bunch of unhappy users sitting quietly saying nothing in my opinion, because as soon as something better comes along everyone is going to jump ship! And, if you review my question I didn't word it in a way that makes it sound like I want everyone to agree that it sucks - it seems to me you are trying to dramatise the post!

"You use a lot of vague anecdotes "

Not vague anecdotes - facts. I lost 2 days - it happened. Nuget bugs were to blame.

"If you are actually interested in improving Nuget, then by all means post the specifics of your problems"

I think I covered this when I mentioned that all the bugs were already well documented and hadn't been fixed despite this.

"80+ projects - an edge case scenario"

Maybe in your experience - not in mine.

I think you are also missing the fact that the first 2 respondents actually agreed - which kind of confirms what I was thinking in the first place - that it kind of sucks!