Why can't I copy assemblies like Example.Contracts.dll and CPlugin.Net.Attributes.dll to the plugin output directory?

[DevD4v3]

This avoids copying the assemblies to the plugin output directory:
https://github.com/MrDave1999/CPlugin.Net/blob/3d81cb52f65ff0bcf3ce281b6a0b558385f046d3/samples/Plugins/Directory.Build.props#L19-L27

https://github.com/MrDave1999/CPlugin.Net/blob/3d81cb52f65ff0bcf3ce281b6a0b558385f046d3/samples/Plugins/Directory.Build.props#L29-L32

[DevD4v3]

1. What happens is that the host application already references these assemblies, so they will be copied to the host output directory.

See,
https://github.com/MrDave1999/CPlugin.Net/blob/8b2120f432c074cb229f6630d6fa462831d2b93a/samples/HostApplications/ConsoleApp/Example.HostConsoleApp.csproj#L12-L13

https://github.com/MrDave1999/CPlugin.Net/blob/8b2120f432c074cb229f6630d6fa462831d2b93a/samples/HostApplications/WebApi/Example.HostWebApi.csproj#L14-L15

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: Example.Contracts.dll and CPlugin.Net.Attributes.dll.

However, the host application is an assembly and so are its dependencies, so they are loaded in a default context (including assemblies as Example.Contracts.dll and CPlugin.Net.Attributes.dll).

Now let's look at this code:
https://github.com/MrDave1999/CPlugin.Net/blob/904775f90fcc15bde7a141ec99c1406002bd29ce/src/Core/TypeFinder.cs#L47-L60

This line is important:

var pluginAttributes = assembly.GetCustomAttributes<PluginAttribute>();

assembly contains an instance of type Assembly that represents the plug-in itself, which in fact was loaded in its own context.

GetCustomAttributes will always return an empty enumerable and this happens because the .NET runtime does not find the PluginAttribute type of the default context in the current assembly (the plugin as such) that is being evaluated.

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 CPlugin.Net.Attributes.dll in the default context and not in the custom context of your plugin, then there would be no conflict between the types, because the .NET runtime will only use the PluginAttribute type loaded in the default context.

3. The same problem occurs if the Example.Contracts.dll assembly is shared between the default and custom context.

This condition will always be false:

if (typeof(TSupertype).IsAssignableFrom(implementationType))
   yield return (TSupertype)Activator.CreateInstance(implementationType);

I will assume TSupertype is ICommand. This type is loaded both in the default context and in the custom context.
Now imagine that my plugin has a subtype called HelloCommand that implements ICommand.
That condition will be false because HelloCommand does not implement the ICommand that is loaded in the default context, but the one in the custom context. So the .NET runtime takes these two types as different, since they are loaded in different contexts.