1
votes

I have a program that loads plugins at runtime. I iterate through each directory in the "Plugins" directory and attempt to load the DLL found. Each plugin has its own directory with the plugin DLL file and another directory called "Dependencies". If the plugin's DLL invokes the AssemblyResolve event I do the following:

  • Check if assembly is already in current AppDomain and return it if it is
  • Check the plugin's Dependencies directory for the DLL and attempt Assembly.LoadFrom
  • If no condition was met or last LoadFrom call fails just return null

Plugins that have no 3rd party dependencies or simple ones like Newtonsoft.Json or NHibernate load just fine. I have one plugin that depends on a DLL we'll just call "custom_library.dll." When the AssemblyResolve event is fired looking for this dependency I can confirm the file is in the Dependencies directory like it should be and even a File.Exists() call returns true.

Unfortunately the Assembly.LoadFrom() call for this DLL throws a FileLoadException with the message "Could not load file or assembly 'custom_library.dll, Version=5.3.136.0, Culture=neutral, PublicKeyToken=null'. Nothing else is provided in the exception beyond HRESULT -2146233079. I can also reference this DLL through Visual Studio without problem.

Why am I getting this exception when trying to load the DLL at runtime instead of through Visual Studio's Add Reference feature?

1
Sounds like custom_library.dll does actually have other dependencies that aren't in your current process's search path. If you use Microsoft's Dependency Walker tool, depends.exe, does it declare any static DLL imports that you weren't aware of? These static references can be caused by usage of the DllImport attribute.AlwaysLearning
When I opened the DLL file in Dependency Walker I get a lot files that are missing. They are API-MS-WIN-CORE, API-MS-WIN-EVENTING, API-MS-WIN-SECURITY, API-MS-WIN-APPMODEL, API-MS-WIN-BASE, API-MS-WIN-COREUI, API-MS-WIN-CRT, etc. There's a lot of them. IEFRAME.DLL, SHCORE.DLL and SHLWAPI.DLL are the only ones showing in red. Is this even a .NET DLL? How is it able to be referenced in Visual Studio without error?Logan K
Is the plugin DLL targeting the same framework as your process? is it using the same platform (x86/x64)?Idov

1 Answers

1
votes

Assembly.LoadFrom was failing because the 3rd party DLL that I was trying to reference was built as a .NET Framework project and I was in a .NET Core project. I confirmed this by creating my own DLL with one class as a .NET Framework Class Library project and received the same error. Once I took the exact same thing and built it targeting .NET Standard 2.0 everything loaded fine.

I spoke with the vendor and once they provided a different DLL that targeted .NET Standard the DLL was able to load and find all of its dependencies without issue.