Reputation: 4865
At some point in an AssemblyResolve
handler I have tried to load assemblies coming with complex app.config
scheme in a separate domain to let this domain dynamically solve assemblyBinding
found in the configuration file for me (as I cannot change current domain bindings once it is running).
Anyhow I noticed that, even if setting correctly ApplicationBase
, PrivateBinPath
, and ConfigurationFile
, and checking very carefully for deployed version of assemblies:
app.config
)Here is shortened version of code for illustration:
static void Main(string[] args)
{
// Init
var configFilename = Path.GetFullPath(@".\..\..\TestApp\TestApp.exe.config");
var configFolder = Path.GetDirectoryName(configFilename);
// Emulate same 'AssemblyResolve' callback arguments
var resolveEventArgs = new ResolveEventArgs("System.Memory, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51", null);
// Create separate domain to resolve third - party using same 'app.config' scheme
var setup = new System.AppDomainSetup()
{
ApplicationName = "CrashTestDummies",
ApplicationBase = configFolder, // Use same folder as config for application
PrivateBinPath = configFolder, // and private assemblies probing
ConfigurationFile = configFilename, // and force to use config
};
var crashTestDomain = System.AppDomain.CreateDomain("CrashTestDummies", null, setup);
// Ask other domain to load the assembly for us (hence solving dynamically for app.config binding stuff)
Directory.SetCurrentDirectory(configFolder); // Try forcing .. did not help :(
var arequestinfo = new AssemblyName(resolveEventArgs.Name);
var asmInCrashDomain = crashTestDomain.Load(arequestinfo);
}
This code will fail on final Load
operation with following exception:
Cannot load file or assembly 'System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. File not found.
So all looks like redirection from 4.0.1.1
to 4.0.1.2
as per ConfigurationFile
has been ok but then it fails to find the file (eventhough it is really there with correct Version/Culture/PublicKeyToken ... loading directly 'System.Memory.dll' has no issue).
I since solve my issue by directly loading "System.Memory.dll" file without any check during AssemblyResolve
anyhow I'm still curious why separate domain approach is not working fully (redirection ok, but finding file ko).
Upvotes: 0
Views: 14