DotNetCorePlugins icon indicating copy to clipboard operation
DotNetCorePlugins copied to clipboard

[Question] type sharing when plugin has a newer version of a dependency?

Open FramnkRulez opened this issue 3 years ago • 1 comments

Is type sharing supported when a plugin has a newer version of a dependency than the host process? I am having issues getting this to work when I deploy a plugin with an interface from an assembly with a slighly higher build version (no breaking interface changes). I load the plugin assembly as per examples:

using (var loader = McMaster.NETCore.Plugins.PluginLoader.CreateFromAssemblyFile(pluginPath, config => config.PreferSharedTypes = true))

(In this case I'm setting default behavior to prefer all, but I've also tried explicitly listing the interface with no luck).

Then I run this code to verify the interface I loaded is assignable:

foreach (var pluginType in loader .LoadDefaultAssembly() .GetTypes() .Where(t => typeof(IPlugin).IsAssignableFrom(t) && !t.IsAbstract))

However the 'IsAssignableFrom(t)' is always false when I attempt to load a plugin where the IPlugin interface is contained in a slightly higher build than the host process. The only difference in the IPlugin interface is that the host loads it from an assembly versioned 1.0.3.15 and the plugin includes it from an assembly versioned 1.0.4.3 (an intentional change on my part to repro this - no code changes at all between these versions).

I was under the impression this was what type sharing was designed to solve, but perhaps I am using it incorrectly or have wrong expectations? How would I go about troubleshooting this?

FramnkRulez avatar Feb 01 '22 21:02 FramnkRulez

I've hit the same issue recently, though I don't have a definitive test to say when this began happening. In my case, I was lucky that it was an internal package that was setting the version higher and was able to lower it for the time-being.

That said, I agree and thought this was what preferred types was supposed to fix, by forcing the assembly using the higher version to unify with the host, but that was not working with any of my configurations.

jeddytier4 avatar Apr 20 '22 02:04 jeddytier4

same issue here.

NicolasDorier avatar Dec 15 '22 00:12 NicolasDorier

I tracked that down to https://github.com/natemcmaster/DotNetCorePlugins/blob/main/src/Plugins/Loader/ManagedLoadContext.cs#L102 throwing an exception if the version assemblyName is higher than the version in the default load context.

NicolasDorier avatar Dec 15 '22 02:12 NicolasDorier

I published a new package BTCPayServer.NETCore.Plugins.Mvc or BTCPayServer.NETCore.Plugins which is a fork of this project with the fix in the PR. I @natemcmaster merge my PR or address it, then I advise you to use nate's package instead.

NicolasDorier avatar Dec 15 '22 07:12 NicolasDorier

This issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please comment if you believe this should remain open, otherwise it will be closed in 14 days. Thank you for your contributions to this project.

github-actions[bot] avatar Dec 16 '23 01:12 github-actions[bot]

Closing due to inactivity. If you are looking at this issue in the future and think it should be reopened, please make a commented here and mention natemcmaster so he sees the notification.

github-actions[bot] avatar Dec 31 '23 01:12 github-actions[bot]