The tutorial use a custom ALC (AssemblyLoadContext) to load only one plugin assembly which doesn't depend on others.
In your case, the custom ALC load the plugin and resolve all dependencies.
In the custom ALC, you note that it uses AssemblyDependencyResolver ( a new class in .Net Core 3.0+)
The AssemblyDependencyResolver class enables the application developers to more easily develop a plugin architecture in conjunction with custom System.Runtime.Loader.AssemblyLoadContext instances to isolate plugins and also enable plugins to load dependencies.
Important Remark:
Plugins should include ExcludeAssets=runtime
for project references to shared assemblies, ref.
For example, If the project Common
that include the interface `IContract' and is referenced by the both host application and the plugin project, add reference as given below:
<!-- in the plugin project -->
<ItemGroup>
<ProjectReference Include="..\IContract\Common.csproj">
<Private>false</Private>
<ExcludeAssets>runtime</ExcludeAssets>
</ProjectReference>
<ProjectReference Include="..\MyLibObjectsLib\MyLibObjectsLib.csproj" />
</ItemGroup>
This code is used for loading the plugin:
string pluginPath = @"path/to/MyContract.Plugin.dll";
var assembly = new PluginLoadContext(pluginPath).LoadFromAssemblyPath(pluginPath);
var type = assembly.GetTypes()
.FirstOrDefault(t => t.IsAssignableFrom(t) && !t.IsInterface && !t.IsAbstract);
if (type != null) {
var instance = (IContract)Activator.CreateInstance(type);
var ret = instance.Execute();
}
I simulated your plugin as standard2.0 library and the plugin reference OLEDB nuget package and the plugin is loaded without errors.