1 year ago
#324940
maglun
Assembly resolution fails for dlls in work directory after upgrading to .NET 6
I am upgrading a program from .NET Framework to .NET 6 and have stumbled upon an issue with assembly loading.
The program is plugin-based with plugin dlls residing in a subfolder of the main folder (the main folder is the working directory of the program). The "core" projects and external dependencies reside in the main folder.
The main folder looks like this:
|-- Program.exe
|-- Utilities.dll
|-- ExternalDependency.dll
|-- plugins
|-- Plugin.dll
Here, ExternalDependency.dll is a dependency of Plugin.dll. The files are copied into this folder structure by a post-build script.
On starting Program.exe, the program loads all dlls in the "plugins" folder. On loading Plugin.dll, the program fails to locate ExternalDependency.dll.
I expect the program to look in the current working directory for the dll. I have confirmed that the working directory is indeed the directory containing ExternalDependency.dll.
If I place ExternalDependency.dll in the plugins folder, it does indeed load correctly. I don't want to to this as I would have to place everything in the same folder in that case (core projects, plugins and external dependencies), which would mess up plugin loading .
I can also attach my own method to resolve the assembly:
AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
In this case, I am able to load the assembly, even just by calling
private Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
return Assembly.LoadFrom(args.Name.Split(',')[0] + ".dll")
}
, which, I suppose, just looks in the current working directory.
Even so, it doesn't seem right to implement my own assembly resolution logic to locate a dll in the working directory. This method seems to hook onto other "failures" as well, specifically with locale-specific resource assemblies that otherwise succeed, probably by some other fallback mechanism.
This used to work on .NET Framework and I can't imagine why it would not work on .NET 6. Is the current working directory not an obvious place to look for assemblies? Is there some configuration file somewhere that controls this? Am I missing something else?
Edit: I should note that most dependencies (several of which follow the same location pattern) are loaded correctly, so this seems to be a problem with just one instance.
c#
.net
assemblies
0 Answers
Your Answer