Comment by zubspace | Hacker News Reader

Comment by zubspace | Hacker News Reader

Parent Full thread

About the 'dependency problem':

It's not as bad as in npm with node_modules, because .NET provides a lot of base functionality in the standard library.

But when you start to use multiple nuget packages, sooner or later you will also enter dependency hell, where managing versions and updates of nuget packages gets very painful.

All in all we have to reference about 10 external libraries. The visual studio nuget package manager started to be frustrating if you need to manage those dependencies in multiple solutions. We therefore switched to Central Package Management [1], but then you realize, that you're just shifting the problem around. Now we have to put the whole dependency tree into the file 'Directory.Packages.props' and have to manage the version of 140 libraries. If there are version conflicts, we force nuget to use the latest version and just hope for the best.

Managing versions of dependencies and dependencies of dependencies is a major pain, but it's an ubiquous pain all programming environments share. And no, .NET won't relieve you from that.

[1] https://docs.microsoft.com/en-us/nuget/consume-packages/cent...

I'm not sure if it will help in your scenario, but faced with a similar problem (~80 project solution, mixed c#/f#, with varying dependencies), I found success with Paket (https://github.com/fsprojects/Paket)

It is much more prevalent in the f# community (at this point `dotnet restore` is a perfectly fine default until you hit trouble), but isn't limited to just being applied there.

Yeah this is probably one of the biggest pain points, but modern tooling is really helping to the tide on this. Dependency management is never fun in any language, and .NET has some quirks which make it a challenge as you say. I switched to .NET from java about 5 years ago now and I'm pretty I !are the switch as .NET just keeps getting better. Dependency management is one of the last pieces of the puzzle to really solve for in terms of getting a much better experience. That said if you're starting a brand new .NET project today you can set up your CI/CD pipelines to do Continuous Deployment and use Renovate to automatically upgrade your dependencies and merge if your tests are green. In addition the trend is for smaller codebases these days which makes it far easier to upgrade major versions of dependencies due to much smaller scope of breaking changes. I think those two things in combination eliminate some of the pain we've all felt with not being able to upgrade several years out of date dependencies in huge monolithic codebases. I'm pretty excited for the future of .NET to be honest.

Did you really mean only 10 external libraries? If you'd said 100 I could understand - I hit a version conflict issue in a recent project on adding what was probably package #60 or so, but solved it easily enough after a bit of googling. And we knew we were using a lot of quite old packages (including .NET 2.1 EF, because of a rare breaking change they introduced with 3.0 that we didn't have a good solution for).

Technically just 2 libs are enough to produce the issue...

Our dev loop playbook at work has an advice to never touch Visual Studio's nuget package manager haha.

Instead, dotnet CLI + VS Codes find+replace does a very good job at managing dependencies. It has never been a pain and on project build, all imported version will be consolidated to a single one anyway.

Reply on news.ycombinator.com