Migrate away from Managed Extensibility Framework (MEF)

[JamieMagee]

Currently, we use Managed Extensibility Framework (MEF) to handle injection of dependencies through Component Detection. MEF was the best way to do Dependency Injection (DI) in .NET Framework, and still is the best way to do application extensibility via plugins. However, in Modern .NET, the most common way to do DI is via the Microsoft.Extensions.DependencyInjection package. I suggest migrating away from MEF and to Microsoft.Extensions.DependencyInjection-style DI for a few main reasons:

1. We don't need the full functionality of MEF
2. Microsoft.Extensions.DependencyInjection has better support, documentation, and developer mindshare
3. Microsoft.Extensions.DependencyInjection has less 'magic'
   1. No loading random DLLs
   2. No decorating classes with [Export] and properties with [Import]

The pattern I suggest migrating to is outline in the Options pattern guidance for .NET library authors documentation. I suggest performing this migration in a few key steps

1. Add dependencies and scaffolding #370

We need to add a reference to Microsoft.Extensions.DependencyInjection.Abstractions in Microsoft.ComponentDetection.Orchestrator and Microsoft.Extensions.DependencyInjection to Microsoft.ComponentDetection. The Microsoft.Extensions.DependencyInjection.Abstractions package contains interfaces and abstract classes required for Dependency Injection which can be implemented by any library. We need to use this package specifically in our library (Microsoft.ComponentDetection.Orchestrator) because we don't know which DI library our caller will be using. In our CLI tool, Microsoft.ComponentDetection, we'll use the Microsoft implementation (Microsoft.Extensions.DependencyInjection) of the abstractions provided in Microsoft.Extensions.DependencyInjection.Abstractions

We also need to add an extension method to IServiceCollection called AddComponentDetection. This is where we'll eventually configure all the required services. This extension should initially be private to our assembly, so we can rapidly iterate on the design, without the changes being semver breaking changes.

internal static class ServiceCollectionExtensions
{
    /// <summary>
    /// Register Component Detection services.
    /// </summary>
    /// <param name="services">The <see cref="IServiceCollection" /> to register the services with.</param>
    /// <returns>The <see cref="IServiceCollection" /> so that additional calls can be chained.</returns>
    public static IServiceCollection AddComponentDetection(this IServiceCollection services) => services;
}

This is already complete in #370

2. Add class constructors

Microsoft.Extensions.DependencyInjection works on constructor injection, whereas MEF works on property injection. As we currently use MEF, most of our classes don't have the required constructors (only the default parameterless constructors created by Roslyn).

For example, the DockerService class would need to have the following constructor added

[Export(typeof(IDockerService))]
public class DockerService : IDockerService
{
    public DockerService(ILogger logger)
    {
        this.Logger = logger;
    }

    [Import]
    public ILogger Logger { get; set; }
}

This needs to be done for all classes that are currently annotated with the [Export] attribute.

3. Replace DetectorTestUtility

DetectorTestUtility provides a fluent API to easily set up detector unit tests. Unfortunately, it uses property injection instead of constructor injection to set up the classes.

We need to refactor DetectorTestUtility to use constructor injection, while still providing the mocking capabilities and fluent API if possible.

4. Wire up classes

In our ServiceCollectionExtensions class, we need to wire up all the classes that are currently annotated with the [Export] attribute. For example:

public static IServiceCollection AddComponentDetection(this IServiceCollection services)
{
    services.AddSingleton<IComponentDetector, DockerfileComponentDetector>();
    services.AddSingleton<IComponentDetector, NpmComponentDetector>();
    // etc.

    return services;
}

4. Migrate Microsoft.ComponentDetection

At this point we can migrate Microsoft.ComponentDetection to use ServiceCollection and AddComponentDetection. For example:

var serviceCollection = new ServiceCollection()
    .AddLogging(configure =>
        // ...
    )
    .AddComponentDetection();

See Dependency injection in .NET for more guidance.

5. Make ServiceCollectionExtensions public

At this point Microsoft.ComponentDetection should be using Microsoft.Extensions.DependencyInjection to handle dependency injection. So, if not done already, we should expose ServiceCollectionExtensions (and AddComponentDetection as part of our public API, so consumers of Component Detection (like https://github.com/microsoft/sbom-tool) can use it too.

6. Remove MEF attributes

We should remove any MEF attributes, like [Export] and [Import].

7. Remove public properties

At this point we need to make a breaking API change by removing the public properties that MEF used to configure dependencies. For example, DockerService would change from:

[Export(typeof(IDockerService))]
public class DockerService : IDockerService
{
    public DockerService(ILogger logger)
    {
        this.Logger = logger;
    }

    [Import]
    public ILogger Logger { get; set; }
}

to

[Export(typeof(IDockerService))]
public class DockerService : IDockerService
{
    private readonly ILogger logger;

    public DockerService(ILogger logger)
    {
        this.logger = logger;
    }
}

8. Remove MEF dependencies

Finally, we need to remove the nuget packages that provide the MEF functionality. These are:

• System.Composition.AttributedModel
• System.Composition.Convention
• System.Composition.Hosting
• System.Composition.Runtime
• System.Composition.TypedParts