PluginFramework

New features:

Added PreferPlugin option to UseHostApplicationAssemblies

UseHostApplicationAssemblies is used to determine what happens if the host application and the plugin reference the same DLL but a different version. Common example is that the plugin and host reference different versions of Newtonsoft.Json.

Previously UseHostApplicationAssemblies supported three options:

    /// <summary>
    /// Never use user host application's assemblies
    /// </summary>
    Never,
    
    /// <summary>
    /// Only use the listed hosted application assemblies
    /// </summary>
    Selected,
    
    /// <summary>
    /// Always try to use host application's assemblies
    /// </summary>
    Always,

Now a fourth one has been added:

    /// <summary>
    /// Prefer plugin's referenced assemblies, fallback to host application's assemblies
    /// </summary>
    PreferPlugin

The idea is that if a plugin can't locate the referenced DLL, it fallbacks to the host.

This sounds like a big new feature but actually functionality wise nothing except logging changes compared to the UseHostApplicationAssembliesEnum.Never. The Never-option already returned Null from Plugin's AssemblyLoadContext if the referenced DLL wasn't found, meaning loading reverted to host's assemblies. But previously it wrote a warning log. Now there is no warning message.

New features:

Support for resolving native and platform specific DLLs in NugetPackagePluginCatalog

The NugetPackagePluginCatalog can now resolve native and platform specific DLLs. It also can resolve the best matching DLL inside a Nuget package with more accuracy than before.

This functionality allows the usage of packages like Microsoft.Data.SqlClient as plugins.

Option to provide AssemblyHints to PluginAssemblyLoadContext

PluginAssemblyLoadContext is the class which loads the correct DLLs. It is now possible to provide AssemblyHints to this functionality. The hints can be used to fine tune the DLLs which the PluginAssemblyLoadContext loads.

For example if your system requires as MySystem.dll from the root of your application folder and you know that runtime you actually want to use the MySystem.dll from c:\temp, you can provide the following hint to the context:

var runtimeAssemblyHint = new RuntimeAssemblyHint(fileName: "MySystem.dll", path: @"c:\temp\MySystem.dll", isNative: false);

Hints can be provided through the catalog's PluginLoadContextOptions:

var runtimeAssemblyHint = new RuntimeAssemblyHint(fileName: "MySystem.dll", path: @"c:\temp\MySystem.dll", isNative: false);

var opt = new FolderPluginCatalogOptions();
opt.PluginLoadContextOptions.RuntimeAssemblyHints.Add(runtimeAssemblyHint);

var folderCatalog = new FolderPluginCatalog(@"c:\dev\mysystem\bin", opt);

New features:

Removed MinVer from published packages

MinVer is now declared as a PrivateAsset. This means that MinVer should not be visible when using the published version of Plugin Framework.

Updated NugetDownloader

NugetDownloader dependency has been moved from 1.0.0 to 1.1.0. The 1.0.0 used unofficial .NET Standard version of the Nuget PackageManagement library. In 1.1.0 this has been replaced with official and more up-to-date version.

Allow to use system feeds in addition to the specified feed in Nuget Package Catalog

It's possible to provide the feedurl when using Nuget Package Catalog. Now it is also possible to use the system feeds in addition to the specified feedurl.

This can be configured using the NugetPluginCatalogOptions.IncludeSystemFeedsAsSecondary.

Bug fixes:

FolderPluginCatalog now removes duplicate dlls in addition to duplicate paths

Previously it was possible to have a situation where a same dll was used in FolderPluginCatalogs assembly scanning, but from different locations. Now, the duplicate dlls are removed based on the file name in addition to removing the duplicate paths.

Logging fixes

Fixed an issue where PluginAssemblyLoadContext didn't log messages correctly.

New features:

#24 Allow configuring default plugin that is returned from DI

ASP.NET Core specific new feature which extends the AddPluginType-feature with an option to configure the default plugin type. Here's how this feature can be used:

Previously always resolved the first IOperator:

            services.AddPluginType<IOperator>();

Now:

            services.AddPluginType<IOperator>(configureDefault: option =>
            {
                option.DefaultType = (provider, types) => typeof(SumOperator);
            });

Or:

            services.AddPluginType<IOperator>();
            
            services.Configure<DefaultPluginOption>(nameof(IOperator), option =>
                option.DefaultType = (serviceProvider, implementingTypes) => typeof(MultiplyOperator));

Please view #24 for more details for the background of this feature.

Bug fixes:

#44 Unnecessary assembly loading

Fixed a bug which caused FolderPluginCatalog to load more assemblies than needed when FolderPluginCatalogOptions were used to define the type finding criteria.

New features:

Add support for tagging plugins in Roslyn catalog

It's now possible to tag Roslyn based catalogs. This feature was previously available in all the other catalogs and now also Roslyn catalog supports it.

Examples:

    [Fact]
    public async Task CanTagCode()
    {
        // Arrange
        var code = @"public class MyClass
               {
                   public void RunThings()
                   {
                       var y = 0;
                       var a = 1;
       
                       a = y + 10;
                   
                       Debug.WriteLine(y + a);
                   }
               }";

        var catalog = new RoslynPluginCatalog(code, new RoslynPluginCatalogOptions() { Tags = new List<string>() { "CustomTag" } });

        await catalog.Initialize();
        var plugin = catalog.Single();

        Assert.Equal("CustomTag", plugin.Tag);
    }

    [Fact]
    public async Task CanTagScript()
    {
        // Arrange
        var code = "Debug.WriteLine(\"Hello world!\");";

        var catalog = new RoslynPluginCatalog(code, new RoslynPluginCatalogOptions() { Tags = new List<string>() { "CustomTag" } });

        await catalog.Initialize();

        var plugin = catalog.Single();

        Assert.Equal("CustomTag", plugin.Tag);
    }

New features:

Add support for default naming options

Previously, it was possible to set catalog-specific naming options. These options can be used to override the default logic of deciding the plugin's name and version. The latest version adds the option of setting catalog type specific default options.

The use case for this feature is an application which creates catalogs in multiple places. Instead of having to remember to pass catalog options to each new catalog, you can configure the default naming options once, when the application starts.

The following catalog types support this:

• Assembly
• Type
• Folder
• NugetPackage
• NugetFeed

You can configure the naming options like this:

            AssemblyPluginCatalogOptions.Defaults.PluginNameOptions = new PluginNameOptions()
            {
                PluginNameGenerator = (nameOptions, type) => type.FullName + "Modified"
            };

You can override the default options when creating a catalog:

            AssemblyPluginCatalogOptions.Defaults.PluginNameOptions = new PluginNameOptions()
            {
                PluginNameGenerator = (nameOptions, type) => type.FullName + "Modified"
            };

            var options = new AssemblyPluginCatalogOptions()
            {
                PluginNameOptions = new PluginNameOptions() { PluginNameGenerator = (nameOptions, type) => type.FullName + "Overridden" }
            };

            var catalog = new AssemblyPluginCatalog(@"..\..\..\..\..\Assemblies\bin\netstandard2.0\TestAssembly1.dll");
            var catalog2 = new AssemblyPluginCatalog(@"..\..\..\..\..\Assemblies\bin\netstandard2.0\TestAssembly2.dll", options);

            await catalog.Initialize();
            await catalog2.Initialize();

            var catalog1Plugins = catalog.GetPlugins();

            foreach (var plugin in catalog1Plugins)
            {
                Assert.EndsWith("Modified", plugin.Name);
            }

            var catalog2Plugins = catalog2.GetPlugins();

            foreach (var plugin in catalog2Plugins)
            {
                Assert.EndsWith("Overridden", plugin.Name);
            }

New features:

#1 Add support for appsettings.json

It's now possible to configure assembly and folder catalogs using appsettings.json. Sample is available in https://github.com/weikio/PluginFramework/tree/master/samples/WebAppWithAppSettings

#20 Get plugins by tag

The tagging functionality has been improved. All the catalogs support tags and its possible to set global tagging rule. The idea with tags is that one can use tags to group and find plugins. A sample is available in https://github.com/weikio/PluginFramework/tree/master/samples/WinFormsApp

Bug fixes:

#33 Plugin catalogs sometimes fail to initialize before the request starts in ASP.NET Core

The ASP.NET Core application sometimes started accepting requests before the plugin catalogs were initialized. This was most seen with the Nuget catalog.

Many other smaller tweaks and fixes