Hacker News Reader

Comment by mattherman | Hacker News Reader

What are some of your specific complaints about NuGet? I've never disliked it that much. For the most part it has "just worked" for me.

View on HN

In large projects, NuGet takes FOREVER to resolve package dependencies - I mean 4+ minutes on a new i7 Thinkpad w/16gb RAM/1TB ssd.

Heaven-forbid you want to upgrade a package that exists in all 130 projects in the solution (not my call to have that many projects) - you may as well take a long lunch. I will try to make that the last task of the day so I can let it run for as long as it needs to.

The VS UI for NuGet is terribly buggy.

Uauu! 4+ minutes.

Try to build a C++ or Android project and then go for lunch instead.

NuGET is great.

That's 4 minutes to resolve one NuGet package's dependencies - not 4 minutes for a build.

Really? I never had it take that long.

Usually it doesn't take that long - but it is still generally, unacceptably slow IMO.) Last week I was working on fixing duplicate (version mismatches) package references in the our csproj files) in the branch/solution and I couldn't believe that took 4 minutes to resolve a single reference (after fixing the issue in this particular project!)

I see, I guess I have been lucky then.

NuGet / VS has no qualms with having two references to the same package, but different versions in the project file (i.e. Newtonson.Json.dll 9.0 and 10.0) The build will likely fail though and you'll get no visual feedback that there are two refs in the VS NuGet UI. How did we we get in that state to begin with? I suspect through bad project file merges (or possibly NuGet UI bugs, can't say for sure.)

> How did we we get in that state to begin with? I suspect through bad project file merges (or possibly NuGet UI bugs, can't say for sure.)

Most likely someone modified the packages for an individual project and not the solution as a whole. Always manage packages at the solution level and your much less likely to have these issues, unless you have multiple solutions...

That sounds great when you have a small team, with 30+ devs it's hard to police.

- no local dependencies^ - 'unable to resolve x, arbitrarily picked 1.4.3' - no lock file - nuspec file configuration hell - nuget v2 and v3 feeds arbitrarily going down - installing a specific nuget version on anything other than windows.

Basically, it 'just works' for simple senarios, its just not very good for anything else.

If you want a comprehensive guide to why its not awesome look at the 'packet' website, they cover the issues quite clearly.

^ you can actually use local dependencies, but its irritating and poorly supported (still uses the global system cache, forcing a cache flush to update).

When you install a package, nuget will install old dependencies of that package.

Reply on news.ycombinator.com