Building Extensible .NET Core Applications with MEF

A plugin architecture lets an application gain new capabilities without changing its central business logic every time a feature is added. In a .NET Core or modern .NET solution, Managed Extensibility Framework (MEF) can provide a practical composition model for discovering implementations, matching them to contracts, and assembling services at runtime.

This approach suits systems that need interchangeable modules: reporting providers, payment connectors, document handlers, workflow steps, or AI services. It is especially useful for software teams working across Sydney, Melbourne, Brisbane, and other Australian technology hubs, where products often need to integrate with changing cloud services, local compliance requirements, and separate customer deployments.

Why a plugin architecture helps

A conventional application often grows around a large dependency-injection registration file and a collection of conditional statements. Adding a new provider may require editing core code, rebuilding the entire product, and releasing it to every customer. A plugin design moves optional functionality into separate assemblies with clear contracts.

MEF addresses this problem through composition. A host defines an interface, while an extension marks a class as an export that fulfils that interface. The host scans suitable assemblies, discovers the exports, and injects them into a collection or a selected service. The core application remains relatively stable while modules evolve independently.

This model is valuable for products with customer-specific editions. A logistics application might load a carrier integration for Melbourne and another for Perth; a learning platform could enable separate content providers; an internal tool might install an Azure storage module in one environment and a local file module in another.

The design also supports parallel development. A team can work on the host, while other developers build plugins against a versioned contract package. The same separation can make conference demonstrations and technical prototypes easier to maintain, much like the performance considerations discussed in ValueTask resource pools.

Selecting the right MEF libraries

MEF has more than one programming model, so package selection should be deliberate. The older System.ComponentModel.Composition API is familiar to many .NET Framework developers and uses attributes such as Export and Import. For .NET Core and modern .NET, the System.Composition family is commonly considered the cleaner MEF 2 option, with packages such as System.Composition.Hosting, System.Composition.Runtime, and System.Composition.TypedParts.

The MEF 2 style uses a ContainerConfiguration to assemble parts. A simplified host might look like this:

using System.Composition.Hosting;
using System.Reflection;

var configuration = new ContainerConfiguration()
    .WithAssembly(typeof(IReportExporter).Assembly)
    .WithAssembly(Assembly.LoadFrom(pluginPath));

using var container = configuration.CreateContainer();
var exporters = container.GetExports<IReportExporter>();

The exact package versions and supported target frameworks should be checked before committing to a production design. A solution targeting .NET 8 may have different dependency constraints from a long-lived .NET Core 3.1 product, and trimming or single-file publishing can affect reflection-based discovery.

MEF is a composition framework rather than a complete plugin security boundary. It can locate and construct components, but it does not automatically make untrusted code safe. If a third-party assembly could be malicious, use a separate process, operating-system permissions, container isolation, or a carefully controlled extension marketplace instead of loading it directly into the application process.

Defining stable contracts

The contract assembly is the most important part of the design. Keep it small, dependency-light, and focused on business capabilities rather than implementation details. A contract might contain an interface, a request model, a result model, and a small set of error abstractions:

public interface IReportExporter
{
    string Format { get; }

    Task<ExportResult> ExportAsync(
        ReportData report,
        CancellationToken cancellationToken);
}

public sealed record ExportResult(
    string ContentType,
    byte[] Content);

The host should depend on this assembly, while plugins reference it without referencing the host’s web project, database layer, or user-interface code. That prevents circular dependencies and makes the extension point portable across a console worker, ASP.NET Core service, or desktop administration tool.

Versioning deserves attention from the start. Adding a new method to an interface can break every existing plugin. Prefer a new interface, optional capability interface, or an adapter when a contract must grow. Use semantic versioning and document whether the host guarantees backward compatibility for one, two, or more plugin generations.

Avoid leaking framework-specific objects through the contract. Passing HttpContext, an Entity Framework DbContext, or an internal configuration class ties every extension to one host implementation. Plain records, interfaces, cancellation tokens, and carefully designed service abstractions are easier to test and upgrade.

Discovering and loading extensions

There are two common discovery strategies. The first scans a known directory for assemblies, loads each candidate, and asks MEF to inspect its exported parts. The second uses a configured list of assemblies, which offers stronger control and more predictable startup. Directory scanning is convenient for administrators, while explicit registration is easier to audit.

A plugin can expose an implementation with an export attribute:

using System.Composition;

[Export(typeof(IReportExporter))]
public sealed class CsvReportExporter : IReportExporter
{
    public string Format => "csv";

    public Task<ExportResult> ExportAsync(
        ReportData report,
        CancellationToken cancellationToken)
    {
        var bytes = CreateCsv(report);
        return Task.FromResult(
            new ExportResult("text/csv", bytes));
    }
}

The host can request all exporters, select one by metadata, or compose a named capability. Metadata is useful when the plugin contract is broad:

[Export(typeof(IReportExporter))]
[ExportMetadata("Format", "csv")]

For larger products, place each extension in its own directory with its dependency files and manifest. Record the assembly name, plugin version, contract version, supported operating systems, and required configuration. This reduces ambiguity when several plugins depend on different versions of the same library.

Assembly loading becomes more complex when plugins carry conflicting dependencies. Modern .NET provides AssemblyLoadContext, which can help isolate load contexts, but it does not solve every compatibility issue. If extensions need independent lifecycles or potentially conflicting native libraries, an out-of-process plugin model may be a better fit than in-process MEF composition.

Managing dependencies and lifetimes

MEF composition and ASP.NET Core dependency injection can work together, but their responsibilities should be clear. MEF can discover plugin types, while the application’s service provider supplies logging, options, HTTP clients, and database abstractions. A plugin should receive host services through explicit imports or a small service facade rather than creating its own global service provider.

Constructor injection is generally preferable because it makes required dependencies visible. Optional imports can be appropriate for capabilities that a plugin can operate without, but excessive optional composition tends to hide configuration failures. A missing required export should produce a clear startup error that identifies the contract and assembly involved.

Lifetime decisions matter for resources such as sockets, caches, and database connections. A stateless exporter may be safely reused, while a component holding request-specific state should be created per operation. Async methods should accept cancellation tokens and avoid blocking calls, especially when a plugin runs inside an ASP.NET Core request.

Configuration should be isolated by plugin name or identifier. For example, Plugins:Csv:Delimiter is easier to manage than a collection of unrelated global keys. Secrets should come from a managed secret store or environment-specific provider rather than from a plugin DLL or checked-in JSON file. Teams deploying to Azure Australia East or Australia Southeast can then keep regional settings and credentials separate without recompiling extensions.

Testing, diagnostics, and operational safety

A plugin contract needs its own test suite. Contract tests can verify that every implementation returns valid content types, honours cancellation, handles empty input, and produces useful failures. The host should also test composition with missing assemblies, duplicate exports, incompatible versions, and malformed plugin metadata.

Logging should identify the plugin name and version in every important event. Startup logs can show discovered extensions, rejected assemblies, and composition errors. Health checks may report whether a required plugin is available, while optional extensions can be marked degraded rather than bringing down the whole service.

Australian deployments may process personal information covered by the Privacy Act 1988 and the Australian Privacy Principles. A plugin that exports reports, sends customer data to a SaaS endpoint, or records diagnostic payloads needs a clear data-flow review. Data residency, retention, access controls, and breach-response procedures should be considered alongside technical composition.

The same discipline applies to licensing and procurement. A plugin may introduce a commercial dependency, open-source obligations, or a vendor-specific cloud service. Australian Consumer Law can also be relevant when a product’s advertised capabilities depend on optional modules. Keep a software bill of materials and record which extension version was deployed to each customer environment.

Comparing extensibility approaches

MEF is most attractive when composition should be declarative and extensions are discovered from assemblies. It is less suitable when the system needs strict tenant isolation, polyglot modules, or frequent independent deployment. Comparing it with ordinary dependency injection and process-based integration helps clarify the boundary.

A useful rule is to use MEF when the host and plugins share the same runtime assumptions and a versioned .NET contract. Use built-in dependency injection for application internals that are known at compile time. Choose a separate process or network boundary when the extension has a different release cycle, requires stronger fault containment, or handles sensitive data in a way the host should not directly control.

Practical recommendations for a maintainable design

A production-ready implementation benefits from a small set of explicit engineering rules:

• Keep the contract assembly independent from the host’s UI, database, and web layers.
• Pin compatible MEF package versions and test composition against every supported target framework.
• Validate plugin manifests, versions, capabilities, and configuration before activation.
• Prefer explicit assembly allow-lists when extensions come from controlled deployments.
• Use cancellation, structured logging, and bounded resource lifetimes in every plugin operation.
• Isolate untrusted or failure-prone extensions in a separate process rather than relying on MEF for security.
• Maintain contract tests, a software bill of materials, and a rollback procedure for failed plugin updates.

For teams exploring AI-enabled extensions, the contract can expose a narrow capability such as ITextClassifier or ISummarisationProvider rather than embedding a particular model SDK throughout the host. That keeps providers replaceable as model costs, privacy rules, and latency requirements change; even exploratory machine learning projects benefit from this separation between an application capability and the model implementation.

A well-designed MEF solution therefore has three stable boundaries: the host controls lifecycle and policy, the contract defines capability, and each plugin owns its implementation. With version checks, observability, testing, and Australian data-governance requirements built into those boundaries, the architecture can grow without turning every new integration into a rewrite.