Fix plugin dependency loading by using LoadFromAssemblyPath and modernize PluginLoadContext

[Copilot]

The plugin loader was not correctly loading plugin dependencies, causing plugins that rely on additional NuGet packages to fail at runtime. The issue was in the LoadPluginDLLs method which was using LoadFromAssemblyName instead of properly triggering the dependency resolution mechanism.

Root Cause

The PluginLoadContext class has a Load override method that uses AssemblyDependencyResolver to resolve plugin dependencies:

protected override Assembly? Load(AssemblyName assemblyName)
{
    string? assemblyPath = _resolver.ResolveAssemblyToPath(assemblyName);
    if (assemblyPath != null)
    {
        return LoadFromAssemblyPath(assemblyPath);
    }
    return null;
}

However, LoadPluginDLLs was calling loadContext.LoadFromAssemblyName(assemblyName) which bypasses this override method entirely, preventing dependency resolution from working.

Changes Made

1. Fixed Plugin Loading Method: Changed from:

   var assemblyName = new AssemblyName(Path.GetFileNameWithoutExtension(file));
   var assembly = loadContext.LoadFromAssemblyName(assemblyName);

   to:

   var assembly = loadContext.LoadFromAssemblyPath(file);

   This ensures the Load override is properly invoked for dependency resolution.

2. Modernized PluginLoadContext: Updated to use primary constructor syntax for cleaner, more modern C# code.

3. Improved Test Coverage: Replaced the test dependency from Newtonsoft.Json (which may already be loaded in test context) to SixLabors.ImageSharp, providing a more reliable test of the dependency loading functionality.

Verification

• All existing tests continue to pass
• The specific test for plugin loading with dependencies now properly validates the fix
• Test plugin builds successfully with its dependencies included in output
• Dependencies are correctly listed in the generated .deps.json file

This fix allows plugins to use specialized libraries like image processing, indexing, or other NuGet packages without encountering assembly loading failures.

Fixes #34.

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

• aka.ms
  • Triggering command: curl -I -sSL --retry 5 --retry-delay 2 --connect-timeout 15 REDACTED (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[matt-goldman]

@copilot note this comment added to the issue: #34 (comment)

[Copilot]

@copilot note this comment added to the issue: #34 (comment)

I've already addressed all three concerns you raised in commit 874412e:

1. Fixed plugin loading method: Changed from loadContext.LoadFromAssemblyName(assemblyName) to loadContext.LoadFromAssemblyPath(file) in PluginLoader.cs line 190. This properly triggers the Load override method in PluginLoadContext for dependency resolution.

2. Replaced problematic test dependency: Changed the test plugin from Newtonsoft.Json to SixLabors.ImageSharp which is more obscure and not present in the test context.

3. Modernized PluginLoadContext: Already using primary constructor syntax with PluginLoadContext(string pluginPath) : AssemblyLoadContext(isCollectible: true).

The fixes ensure that plugins with NuGet dependencies can properly load their dependencies through the AssemblyDependencyResolver.

[matt-goldman]

LGTM

[Copilot]

Pull Request Overview

This PR fixes a critical plugin dependency loading issue in Blake's plugin system by changing from LoadFromAssemblyName to LoadFromAssemblyPath and modernizes the plugin loading infrastructure. The fix ensures that plugins requiring external NuGet packages can properly resolve and load their dependencies at runtime.

• Fix plugin dependency resolution by using LoadFromAssemblyPath instead of bypassing the custom load context
• Modernize PluginLoadContext to use primary constructor syntax
• Improve test reliability by switching from Newtonsoft.Json to SixLabors.ImageSharp dependency

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/Blake.BuildTools/Utils/PluginLoader.cs	Changed plugin loading method to properly trigger dependency resolution
src/Blake.BuildTools/Utils/PluginLoadContext.cs	Modernized to use primary constructor and field initialization
tests/Blake.IntegrationTests/TestPluginWithDependencies/BlakePlugin.TestPluginWithDependencies.csproj	Updated test dependency from Newtonsoft.Json to SixLabors.ImageSharp
tests/Blake.IntegrationTests/TestPluginWithDependencies/TestPluginWithDependencies.cs	Replaced JSON serialization with image processing to test dependency loading