From ad6bf53a6d62956034532dcf604935f179cab0df Mon Sep 17 00:00:00 2001 From: meli <57847713+ff-meli@users.noreply.github.com> Date: Tue, 24 Mar 2020 20:05:48 -0700 Subject: [PATCH] Fix for the change to Assembly.LoadFile() no longer correctly handling plugin's local dll dependencies. We still have to use LoadFile() to allow duplicate names, but now we also have to fixup assembly resolution to 'restore' the default behavior. This adds a global appdomain handler that just tries to load dependencies from the local directory of the requesting dll, if other methods have already failed. --- Dalamud/Plugin/PluginManager.cs | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/Dalamud/Plugin/PluginManager.cs b/Dalamud/Plugin/PluginManager.cs index bbea6f304..56755bd53 100644 --- a/Dalamud/Plugin/PluginManager.cs +++ b/Dalamud/Plugin/PluginManager.cs @@ -26,6 +26,22 @@ namespace Dalamud.Plugin this.devPluginDirectory = devPluginDirectory; this.pluginConfigs = new PluginConfigurations(Path.Combine(Path.GetDirectoryName(dalamud.StartInfo.ConfigurationPath), "pluginConfigs")); + + // Try to load missing assemblies from the local directory of the requesting assembly + // This would usually be implicit when using Assembly.Load(), but Assembly.LoadFile() doesn't do it... + // This handler should only be invoked on things that fail regular lookups, but it *is* global to this appdomain + AppDomain.CurrentDomain.AssemblyResolve += (object source, ResolveEventArgs e) => + { + Log.Debug($"Resolving missing assembly {e.Name}"); + // This looks weird but I'm pretty sure it's actually correct. Pretty sure. Probably. + var assemblyPath = Path.Combine(Path.GetDirectoryName(e.RequestingAssembly.Location), new AssemblyName(e.Name).Name + ".dll"); + if (!File.Exists(assemblyPath)) + { + Log.Error($"Assembly not found at {assemblyPath}"); + return null; + } + return Assembly.LoadFrom(assemblyPath); + }; } public void UnloadPlugins() {