-
-
Notifications
You must be signed in to change notification settings - Fork 227
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
Comments
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. |
same issue here. |
I tracked that down to https://github.com/natemcmaster/DotNetCorePlugins/blob/main/src/Plugins/Loader/ManagedLoadContext.cs#L102 throwing an exception if the version |
I published a new package |
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. |
Closing due to inactivity. |
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?
The text was updated successfully, but these errors were encountered: