Better error message when not loading native shared library

[austvik]

Assembly loading problems are frustrating to debug, especially in some cloud world where you don't necessarily have control over regestry settings or env variables in the running environment.

Any error message containing "or" should be banned, but lets start with this one.

The expected error message should be "Failed to load DLL %1, couldn't find it. Searched for it in the following locations: %2" or "Failed to load DLL %1. Couldn't find its dependency %2 which comes from %3 dependency chain. Searched for %2 in the following locations: %4"

I understand that assembly loading needs to be fast, but this extra "give the user some information that can be used" doesn't have to kick into action before after the assembly have failed to load. And by that time I guess most programs doesn't have much meaningfull activity to spend their CPU on anyway.

Bonus: See how the Win version is much doesn't tell you how to get diagnostics (fusion logs should probably be recommended?)

IDS_EE_NDIRECT_LOADLIB_WIN              "Unable to load DLL '%1' or one of its dependencies: %2"
IDS_EE_NDIRECT_LOADLIB_LINUX            "Unable to load shared library '%1' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: %2"
IDS_EE_NDIRECT_LOADLIB_MAC              "Unable to load shared library '%1' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: %2"

[janvorli]

@austvik The error messages given above didn't originally have the "or one of its dependencies" in it. I have added that one to make it actually clearer that the shared library actually may have been there, but its dependencies or dependencies of their dependencies were missing. People were complaining - how come the message tells us that the file is missing when we can see it being there?
Btw, these messages are not related to assemblies, but to native dlls / shared libraries.

The problem is that the .NET runtime doesn't know which dependencies were missing. Basically, we ask the OS to load a shared library and when it fails to do so because a secondary or lower level dependencies are missing, it just returns a failure exit code. The OS loader is responsible for finding what are the dependency libraries and where they are located based on platform specific algorithms and system wide settings. So we really don't know where the OS loader was looking. That's why there is the suggestion to use LD_DEBUG env var. That instructs the OS loader to log all the locations it used to look for all libraries and their dependencies and also what symbols it was looking for.

[jkotas]

Win version is much doesn't tell you how to get diagnostics (fusion logs should probably be recommended?)

The Windows equivalent of LD_DEBUG / DYLD_PRINT_LIBRARIES is Show loader snaps flag. Perhaps we can update the Windows error message to suggest it.

[austvik]

OK, so those were for native DLLs, and we have the same for managed DLLs:
IDS_EE_FILELOAD_ERROR_GENERIC "Could not load file or assembly '%1'. %2"

I think the argument holds for both: we could save people lots and lots of hours, sometimes making it possible to figure out what went wrong in locked down envs, by adding the information I outlined above to those messages.

People are able to get the useful information both for managed and native code:
https://github.com/isindicic/DependencyWalker.Net

(And if something that runs on top of the CLR is able, then the CLR should be able as well.)

[austvik]

I can confirm that I had the very same problem on Friday which made me inefficient. It is probably still frustrating our customers and wasting their time.