[moron4hire]

DLL Hell doesn't refer to "lots of DLLs", it refers to conflicting versions of DLLs not being easily manageable across multiple applications. Outside of putting assemblies in the GAC (which was always a hack of last resort anyway), .NET has never had "DLL Hell".

[WorldMaker]

Yeah, the closest .NET equivalent is Binding Redirection hell, and NuGet and Visual Studio and .NET Core have spent years of work making that better than it was at its worst in the early NuGet days. There's a couple of low level APIs that are still annoying problems to redirect if you need to support particular sets of .NET Framework and .NET Core, but beyond that a lot of it is managed for developers automatically these days.

[moron4hire]

Yeah, the VS interface for managing it is not great, but the new project file format is a lot easier to understand and manage, so I've had good luck just making manual changes.

[qes]

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

[moron4hire]

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

[pjmlp]

GAC was surely the recommended way until .NET 4.0, when the location changed.

[moron4hire]

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.

[pjmlp]

Initially that recommendation only applied to native code DLLs, not managed ones, as far as I can remember.

[rafaelvasco]

Yeah, lots of assemblies is kinda like .NET dll hell ;) .NET Core had this problem in earlier versions. Not anymore;