Introduction
The concept of middleware has been around since ASP.NET MVC (pre-Core) and OWIN. Essentially, a middleware component lives in a pipeline and handles requests and acts as a chain of responsibility, delegating to any subsequent middleware components registered in the pipeline after itself. The following image (taken from the Microsoft site) shows this.
MVC itself is implemented as a middleware component, as is redirection, exception handling, buffering, etc.
A middleware component can be added in several ways, but in ASP.NET Core, it all goes down to the Use method in IApplicationBuilder. Lots of API-specific methods rely on it to add their own middleware.
For the time being, we'll make use of the IMiddleware interface that comes with ASP.NET Core. It provides a simple contract that has no dependencies other than the common HTTP abstractions.
One common request is the ability to load and inject middleware components dynamically into the pipeline. Let's see how we can
Managed Extensibility Framework
.NET Core has Managed Extensibility Framework (MEF), and I previously blogged about it. MEF offers an API that can be used to find and instantiate plugins from assemblies, which makes it an interesting candidate for the discovery and instantiation of such middleware components.
We'll use the System.Composition NuGet package. As in my previous post, we'll iterate through all the assemblies in a given path (normally, the ASP.NET Core's bin folder) and try to find all implementations of our target interface. After that we'll register them all to the MEF configuration.
Implementation
Our target interface will be called IPlugin and it actually inherits from IMiddleware. If we so wish, we can add more members to it, for now, it really doesn't matter:
public interface IPlugin : IMiddleware { }The IMiddleware offers an InvokeAsync method that can be called asynchronously and takes the current context and a pointer to the next delegate (or middleware component).
I wrote the following extension method for IApplicationBuilder:
public static class ApplicationBuilderExtensions
{
public static IApplicationBuilder UsePlugins(this IApplicationBuilder app, string path = null) {
var conventions = new ConventionBuilder();
conventions
.ForTypesDerivedFrom<IPlugin>()
.Export<IPlugin>()
.Shared();
path = path ?? AppContext.BaseDirectory;
var configuration = new ContainerConfiguration()
.WithAssembliesInPath(path, conventions);
using (var container = configuration.CreateContainer())
{
var plugins = container
.GetExports<IPlugin>()
.OrderBy(p => p.GetType().GetCustomAttributes<ExportMetadataAttribute>(true)
.SingleOrDefault(x => x.Name == "Order")?.Value as IComparable ?? int.MaxValue);
foreach (var plugin in plugins)
{
app.Use(async (ctx, next) =>
{
await plugin.InvokeAsync(ctx, null);
await next();
});
}
}
return app;
}
}
We define a convention that for each type found that implements IPlugin we register it as shared, meaning, as a singleton.
As you can see, if the path parameter is not supplied, it will default to AppContext.BaseDirectory.
We can add to the plugin/middleware implementation an ExportMetadataAttribute with an Order value to specify the order by which our plugins will be loaded, more on this in a moment.
The WithAssembliesInPath extension method comes from my previous post but I'll add it here for your convenience:
public static class ContainerConfigurationExtensions { public static ContainerConfiguration WithAssembliesInPath(this ContainerConfiguration configuration, string path, SearchOption searchOption = SearchOption.TopDirectoryOnly) { return WithAssembliesInPath(configuration, path, null, searchOption); } public static ContainerConfiguration WithAssembliesInPath(this ContainerConfiguration configuration, string path, AttributedModelProvider conventions, SearchOption searchOption = SearchOption.TopDirectoryOnly) { var assemblyFiles = Directory .GetFiles(path, "*.dll", searchOption); var assemblies = assemblyFiles .Select(AssemblyLoadContext.Default.LoadFromAssemblyPath); configuration = configuration.WithAssemblies(assemblies, conventions); return configuration; } }If you want to search all assemblies in nested directories, you need to pass SearchOption.AllDirectories as the searchOption parameter, but this, of course, will have a performance penalty if you have a deep directory structure.
Putting it All Together
So, let's write a few classes that implement the IPlugin interface and therefore are suitable to be used as middleware components:
[Export(typeof(IPlugin))] [ExportMetadata("Order", 1)] public class MyPlugin1 : IPlugin { public async Task InvokeAsync(HttpContext context, RequestDelegate next) { //do something here
//this is needed because this can be the last middleware in the pipeline (next = null) if (next != null) { await next(context); }
//do something here } }
Notice how we applied an ExportMetadataAttribute to the class with an Order value; this is not needed and if not supplied, it will default to the highest integer (int.MaxValue), which means it will load after all other plugins. These classes need to be public and have a public parameterless constructor. You can retrieve any registered services from the HttpContext's RequestServices property.
Now, all we need to do is add a couple of assemblies to the web application's bin path (or some other path that is passed to UsePlugins) and call this extension method inside Configure:
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
//rest goes here
app.UsePlugins(/*path: "some path"*/);
//rest goes here
}
And here you have it: ASP.NET Core will find middleware from any assemblies that it can find on the given path.
Hope you find this useful!