-
Notifications
You must be signed in to change notification settings - Fork 0
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
Why can't I copy assemblies like Example.Contracts.dll and CPlugin.Net.Attributes.dll to the plugin output directory? #27
Comments
1. What happens is that the host application already references these assemblies, so they will be copied to the host output directory. See, CPlugin.Net/samples/HostApplications/ConsoleApp/Example.HostConsoleApp.csproj Lines 12 to 13 in 8b2120f
CPlugin.Net/samples/HostApplications/WebApi/Example.HostWebApi.csproj Lines 14 to 15 in 8b2120f
There is an indirect reference to CPlugin.Net.Attributes project because CPlugin.Net project already makes reference to it. 2. If you copy those assemblies to the plugin output directory as well, you will get unexpected behavior when running the host application. What behavior? FindSubtypesOf method will always return an empty enumerable and even if subtypes exist for a supertype. Now the question is why does this happen? When loading a plug-in, an instance of AssemblyLoadContext is created and in this context these assemblies are also loaded: However, the host application is an assembly and so are its dependencies, so they are loaded in a default context (including assemblies as Now let's look at this code: CPlugin.Net/src/Core/TypeFinder.cs Lines 47 to 60 in 904775f
This line is important: var pluginAttributes = assembly.GetCustomAttributes<PluginAttribute>();
That's right, the host application has the PluginAttribute type loaded in the default context but the plugin also has it in its custom context, so .NET runtime takes it as different types. This is not a bug, it is the behavior expected by the runtime, or at least I think so. So, if you just load the assembly as 3. The same problem occurs if the This condition will always be if (typeof(TSupertype).IsAssignableFrom(implementationType))
yield return (TSupertype)Activator.CreateInstance(implementationType); I will assume |
This avoids copying the assemblies to the plugin output directory:
CPlugin.Net/samples/Plugins/Directory.Build.props
Lines 19 to 27 in 3d81cb5
CPlugin.Net/samples/Plugins/Directory.Build.props
Lines 29 to 32 in 3d81cb5
The text was updated successfully, but these errors were encountered: