Lots of problems with Nuget and Microsoft's use of it
Nuget is pretty much the package manager for .Net. In fact, I don't know if anything else exists for getting framework extensions and third-party libraries.
For really simple things, it just works and I guess that's why no-one has created a competitor but there are some deep problems that become very common when you do anything more than a simple app and which can be incredibly difficult to debug.
1) Visual Studio output window
Why is this window still black and white? Even TeamCity, a web-based Java app can colour-code the build log so it's easy to spot the errors in the 85000 lines of output during a build.
2) Assembly redirects
These have gone in dotnet core but we live with a legacy of terribly confusing errors that even once you have experienced them still make you scratch your head. Nuget very helpfully adds these often when you install packages (and usually changes all the spacing to make it hard to see the diff!). The problem is, they are never removed when you uninstall a package so you often have a direction to the compiler which is out of date and breaks the build.
3) Inconsistent tooling
Visual studio, msbuild, dotnet cli etc. all treat things differently. Support dotnet core? Maybe. Use /p for parameters? Yep, sometimes. Can I do nuget X with dotnet cli? No. What about packing? You can use nuget or msbuild but use dotnet and it might pass it through to something else or not. The amount of time I have wasted trying to work out why something doesn't work only to find some github issue. Nuget needs to go away and be replaced with native dotnet cli support. The documentation should be nice and clear: Nuget is deprecated and dotnet core is the new nuget. Except it isn't, so we can't
4) Cannot package dependencies without using nuspec
If you have Project A references Project B and you want both ProjectA.dll and projectB.dll in the nuget package, it isn't support using dotnet pack. Why not? Because someone didn't think about it and now there is a confusing argument on github about why this is hard. It's not hard, you just have to use nuspec, which isn't hard, just an annoying step. Should be able to say, "treat this as nuget package" and "treat this as dll". The "workaround" is to publish your dependencies as nugets! As if the build process was not convoluted enough as it is, why publish a nuget just so another project can reference it properly?
5) Consolidating nuget packages is insanely slow
I can understand package.configs running scripts being slow but why is a cached list of nuget packages and local csproj files to slow to parse and show you? Why does it take forever to look for a version of something which is basically a zip file with a manifest?
6) Versioning that misleadingly follows dot net framework versions
So you have a dotnet fx 4.6 project and need a nuget, do you install the latest version or version 4.6.0? I think MS thought they could track but then realised that if you need to fix e.g. version 4.6.1, you are screwed because your numbering system will break. This was a major problem with DataAnnotations where they screwed up a dependency but could not retrospectively fix it and so anyone who tried to install it got untolds of conflicting dependencies.
7) Nuget errors don't show enough information.
I have seen in some places where it shows you A => B => C and D => C and you can work out where your dependency is wrong but since most nuget references are >= versions, this should rarely be a problem. Use the newest version unless they are locked to a specific version, which is a genuine conflict. Otherwise, if you try and install a package that you know exists and it fails, you usually get nothing at all to give you a clue what has happened. When using PackageReference and the nuget cache, it's even worse. Did you look in the cache or did you also check the live feed?
8) Errors breaking runtime should break compilation
Why is it that I can build successfully with incompatible versions but then when you try and run, you get the yellow screen of death? These should 100% be compiler errors that you fix immediately and not 2 hours later when something breaks down the line.
9) No verified label
I know a lot of stuff is open source but sometimes when e.g. MS don't provide something, someone else provides an extended version of an MS library that has the same icon and same name pattern but is not official MS. I don't want to install hacks without realising. Give yourselves a blue-tick or something.
10) System libraries as nugets
This was really confusing and I think was part hack and part u-turn on the part of MS. If you want to use system caching, where do you get it from? You used to add it as a direct reference in the assembly reference of the project and "know" it would be present on the destination server. Now partly because of dotnet core and partly because they wanted to reduce the size of the main dotnet runtime, they separated out some of the functionality and you needed these "extension" packages like System.Runtime.Caching, or did you? Sometimes, sometimes not but you can bet your bottom dollar that once these are referenced, they will stay in your project forever causing reference errors for the foreseeable future.
11) Splitting out loads of extension packages
In dotnet core 2, they have Microsoft.Extensions for everything like Options, Configuration, DependencyInjection etc. and this added tonnes of bloat to the CI builds trying to keep packages up to date and a whole load of stuff. Some of these are now part of the main runtime (as they should have been all along) but again, the danger is we live with these forever!
12) No mechanism for unneeded packages to be flagged
In the above example, it would be great if you got an obvious warning like, "Now you have dotnet core 3, you do not need .... package". These can't be warnings in the sea of output but could be perhaps a right-click kind of operation that would make sense after any major upgrades.
13) Scripted functionality not available with package reference
This was a serious breaking change. Packages maybe don't usually need to run scripts but they can and they do. Now the risk is on the Developer that if they use package reference, the packages that used to do something important now won't work. But you might not know until it fails at runtime. Again, a basic piece of functionality like, "This package is trying to run scripts which are not allowed in this type of project" might be useful. The more details it can give, the better.
14) Terrible complex dependencies.
I have lots of examples where I want something simple like AspNetCore.Security and it pulls in about 12 other packages even when I only want a handful of types. This is mostly MS's fault where libraries should always be based on an abstractions library which can be installed standalone. Otherwise a library function that needs these causes everything that uses any method in the helper library to have to reference a tonne more of libraries, each with their own version hell.
For really simple things, it just works and I guess that's why no-one has created a competitor but there are some deep problems that become very common when you do anything more than a simple app and which can be incredibly difficult to debug.
1) Visual Studio output window
Why is this window still black and white? Even TeamCity, a web-based Java app can colour-code the build log so it's easy to spot the errors in the 85000 lines of output during a build.
2) Assembly redirects
These have gone in dotnet core but we live with a legacy of terribly confusing errors that even once you have experienced them still make you scratch your head. Nuget very helpfully adds these often when you install packages (and usually changes all the spacing to make it hard to see the diff!). The problem is, they are never removed when you uninstall a package so you often have a direction to the compiler which is out of date and breaks the build.
3) Inconsistent tooling
Visual studio, msbuild, dotnet cli etc. all treat things differently. Support dotnet core? Maybe. Use /p for parameters? Yep, sometimes. Can I do nuget X with dotnet cli? No. What about packing? You can use nuget or msbuild but use dotnet and it might pass it through to something else or not. The amount of time I have wasted trying to work out why something doesn't work only to find some github issue. Nuget needs to go away and be replaced with native dotnet cli support. The documentation should be nice and clear: Nuget is deprecated and dotnet core is the new nuget. Except it isn't, so we can't
4) Cannot package dependencies without using nuspec
If you have Project A references Project B and you want both ProjectA.dll and projectB.dll in the nuget package, it isn't support using dotnet pack. Why not? Because someone didn't think about it and now there is a confusing argument on github about why this is hard. It's not hard, you just have to use nuspec, which isn't hard, just an annoying step. Should be able to say, "treat this as nuget package" and "treat this as dll". The "workaround" is to publish your dependencies as nugets! As if the build process was not convoluted enough as it is, why publish a nuget just so another project can reference it properly?
5) Consolidating nuget packages is insanely slow
I can understand package.configs running scripts being slow but why is a cached list of nuget packages and local csproj files to slow to parse and show you? Why does it take forever to look for a version of something which is basically a zip file with a manifest?
6) Versioning that misleadingly follows dot net framework versions
So you have a dotnet fx 4.6 project and need a nuget, do you install the latest version or version 4.6.0? I think MS thought they could track but then realised that if you need to fix e.g. version 4.6.1, you are screwed because your numbering system will break. This was a major problem with DataAnnotations where they screwed up a dependency but could not retrospectively fix it and so anyone who tried to install it got untolds of conflicting dependencies.
7) Nuget errors don't show enough information.
I have seen in some places where it shows you A => B => C and D => C and you can work out where your dependency is wrong but since most nuget references are >= versions, this should rarely be a problem. Use the newest version unless they are locked to a specific version, which is a genuine conflict. Otherwise, if you try and install a package that you know exists and it fails, you usually get nothing at all to give you a clue what has happened. When using PackageReference and the nuget cache, it's even worse. Did you look in the cache or did you also check the live feed?
8) Errors breaking runtime should break compilation
Why is it that I can build successfully with incompatible versions but then when you try and run, you get the yellow screen of death? These should 100% be compiler errors that you fix immediately and not 2 hours later when something breaks down the line.
9) No verified label
I know a lot of stuff is open source but sometimes when e.g. MS don't provide something, someone else provides an extended version of an MS library that has the same icon and same name pattern but is not official MS. I don't want to install hacks without realising. Give yourselves a blue-tick or something.
10) System libraries as nugets
This was really confusing and I think was part hack and part u-turn on the part of MS. If you want to use system caching, where do you get it from? You used to add it as a direct reference in the assembly reference of the project and "know" it would be present on the destination server. Now partly because of dotnet core and partly because they wanted to reduce the size of the main dotnet runtime, they separated out some of the functionality and you needed these "extension" packages like System.Runtime.Caching, or did you? Sometimes, sometimes not but you can bet your bottom dollar that once these are referenced, they will stay in your project forever causing reference errors for the foreseeable future.
11) Splitting out loads of extension packages
In dotnet core 2, they have Microsoft.Extensions for everything like Options, Configuration, DependencyInjection etc. and this added tonnes of bloat to the CI builds trying to keep packages up to date and a whole load of stuff. Some of these are now part of the main runtime (as they should have been all along) but again, the danger is we live with these forever!
12) No mechanism for unneeded packages to be flagged
In the above example, it would be great if you got an obvious warning like, "Now you have dotnet core 3, you do not need .... package". These can't be warnings in the sea of output but could be perhaps a right-click kind of operation that would make sense after any major upgrades.
13) Scripted functionality not available with package reference
This was a serious breaking change. Packages maybe don't usually need to run scripts but they can and they do. Now the risk is on the Developer that if they use package reference, the packages that used to do something important now won't work. But you might not know until it fails at runtime. Again, a basic piece of functionality like, "This package is trying to run scripts which are not allowed in this type of project" might be useful. The more details it can give, the better.
14) Terrible complex dependencies.
I have lots of examples where I want something simple like AspNetCore.Security and it pulls in about 12 other packages even when I only want a handful of types. This is mostly MS's fault where libraries should always be based on an abstractions library which can be installed standalone. Otherwise a library function that needs these causes everything that uses any method in the helper library to have to reference a tonne more of libraries, each with their own version hell.