ToxicMushroom/Dalamud
1
0
Fork 0
mirror of https://github.com/goatcorp/Dalamud.git synced 2025-12-12 18:27:23 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 3

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.

Browse source
This commit is contained in:
meli 2020-03-24 20:05:48 -07:00
parent d47d70c012
commit ad6bf53a6d
1 changed files with 16 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

16
Dalamud/Plugin/PluginManager.cs
View file

@ -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() {