Hacker News new | ask | show | jobs
by qes 2324 days ago
> .NET has never had "DLL Hell"

I take it you've never worked on a .Net solution with projects targeting both full framework and Core framework.

Core v1.x stuff was a nightmare - haven't had so many issues with versioning in 20 years. Core v2.0 was still pretty bad but each v2 point release made decent strides - and specific packages would get updated out of band at times to fix issues.

But to say .Net has never had DLL Hell is just wrong. Even pre-Core you could run into difficult situations with conflicting downstream dependencies of directly used packages.
1 comments
moron4hire 2324 days ago
DLL Hell had nothing to do with project development. It was a problem of application deployment and running applications with DLLs in shared locations.

https://en.wikipedia.org/wiki/DLL_Hell

  The problem arises when the version of the DLL on the computer is different than the version that was used when the program was being created.
Other than the GAC, which was never recommended for use anyway, .NET has never had DLL Hell
link
pjmlp 2324 days ago
GAC was surely the recommended way until .NET 4.0, when the location changed.
link
moron4hire 2323 days ago
No, the recommended way was to install your application with all dependency DLLs in the application install location.

And I've misspoken about GAC causing DLL Hell for .NET. It fixed DLL Hell, but introduced a new Strong Naming Hell.

link
pjmlp 2323 days ago
Initially that recommendation only applied to native code DLLs, not managed ones, as far as I can remember.
link