Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
FramnkRulez opened this issue Feb 1, 2022 · 6 comments · May be fixed by #268
Closed

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

FramnkRulez opened this issue Feb 1, 2022 · 6 comments · May be fixed by #268
Labels
closed-stale Closed because the issue got stale and there wasn't any follow-up. question Further information is requested stale

Comments

@FramnkRulez
Copy link

FramnkRulez commented Feb 1, 2022

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 FramnkRulez added the question Further information is requested label Feb 1, 2022
@jeddytier4
Copy link

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.

@NicolasDorier
Copy link

same issue here.

@NicolasDorier
Copy link

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
Copy link

NicolasDorier commented Dec 15, 2022

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.

Copy link

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 github-actions bot added the stale label Dec 16, 2023
Copy link

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 github-actions bot added the closed-stale Closed because the issue got stale and there wasn't any follow-up. label Dec 31, 2023
@natemcmaster natemcmaster closed this as not planned Won't fix, can't repro, duplicate, stale Dec 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-stale Closed because the issue got stale and there wasn't any follow-up. question Further information is requested stale
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants