Yeah, Windows has traditionally been worse than Linux in this capacity, but my point is that dependency management is a non-trivial problem. My experience is that package managers usually work but not always (I've had occasional issues on Arch) and the fact that you need a package manager, and how sophisticated they often have to be, shows how tricky the problem can be to solve.

To be even more specific, it happened because apps dumped DLLs into shared system directories instead of bundling them alongside the app binary. Since on Windows, each app has its own directory, it's easy to bundle in a way that doesn't mess up other apps.

It became so once the DLL search path was changed to put the .exe file's containing folder first.

Prior to that, the system dirs were searched first, which was the trigger for the DLL hell issue.

I mean, if all apps avoided writing to the global folders (i.e. reserve it for OS-managed components), there wouldn't be an issue even with the old arrangement.

But not even Microsoft's own products respected that in practice.

As if Linux is any better, specially regarding glibc.

it is better. (Unix/ELF generically, not linux). versioned symbols are a YUGE improvement over DLLs.

Hence why I explicitly mentioned Linux.

Also Aix uses the same model as Windows.

Finally, .NET Assemblies are versioned, and Microsoft has introduced Application Manifests around Windows XP.

https://docs.microsoft.com/en-us/windows/desktop/sbscs/appli...

So it a matter of actually taking the effort of specifying the versions that the application works with.

> Finally, .NET Assemblies are versioned,

But then, you still have to put up with defining potentially hundreds of <bindingRedirect>s in config files to even get an application to run correctly, even though they mostly don't share their DLLs.

The only thing it takes is Nuget dowloading a newer version of some dependency another library depends on, even if it's backwards compatible with the old API. Which, of course, it should always be if you haven't switched to a new major version.

Edit: Also, I find it very disturbing that the resulting errors always happen to be crashes during runtime instead of up-front. If that happens with a plugin or through reflection: fine. But for most of .NET code, dependencies should be able to be loaded during startup.

All assemblies are versioned and can potentially have unique strong names, not just .NET assemblies. A native DLL can still be an assembly.

https://en.wikipedia.org/wiki/Side-by-side_assembly