5 ms·

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.

GiorgioG 9y ago
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.
- pjmlp 9y ago
  Uauu! 4+ minutes. Try to build a C++ or Android project and then go for lunch instead. NuGET is great.
  - GiorgioG 9y ago
    That's 4 minutes to resolve one NuGet package's dependencies - not 4 minutes for a build.
    - pjmlp 9y ago
      Really? I never had it take that long.
      - GiorgioG 9y ago
        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!)
        pjmlp 9y ago
        I see, I guess I have been lucky then.
aljones 9y ago
When you install a package, nuget will install old dependencies of that package.
GiorgioG 9y ago
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.)
- flukus 9y ago
  > 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...
  - GiorgioG 9y ago
    That sounds great when you have a small team, with 30+ devs it's hard to police.
wokwokwok 9y ago
- 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).

GiorgioG 9y ago

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.

pjmlp 9y ago
Uauu! 4+ minutes. Try to build a C++ or Android project and then go for lunch instead. NuGET is great.
- GiorgioG 9y ago
  That's 4 minutes to resolve one NuGet package's dependencies - not 4 minutes for a build.
  - pjmlp 9y ago
    Really? I never had it take that long.
    - GiorgioG 9y ago
      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!)
      - pjmlp 9y ago
        I see, I guess I have been lucky then.

aljones 9y ago

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

GiorgioG 9y ago

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.)

flukus 9y ago
> 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...
- GiorgioG 9y ago
  That sounds great when you have a small team, with 30+ devs it's hard to police.

wokwokwok 9y ago

- 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).