Introduce

The concept of middleware has been around since ASP.NET MVC (before .NET Core) and OWIN . Basically, a middleware component in a pipeline processes requests and acts as a series of jobs, and is entrusted with any subsequent componennt middleware registered in the pipeline. after it. The image below (taken from the Microsoft website) indicates this.

MVC itself is implemented (implemented) as a middleware component, such as redirection, exception handling, buffering, etc.

A middleware component can be added in several ways, but in ASP.NET Core, it’s all through the Use method in IApplicationBuilder . Many API-specific methods rely on it to add middleware components.

For now, we will use the IMiddleware interface that comes with ASP.NET Core. It provides a simple contract with no dependencies other than HTTP abstractions.

A common request can download and inject middleware components automatically into the pipeline. Let’s see how we can do that.

Managed Extensibility Framework

The .NET Core has a Managed Extensibility Framework (MEF), which you can find out in my previous article Using MEF in .NET Core . MEF proposes an API that can be used to find and initialize plugins from assemblies, which makes it an interesting candidate for discovering and installing middleware components.

We will use the System.Composition Nuget package. As in the previous article, we will loop through all assemblies in the provided paths (usually the bin directory of ASP.NET Core) and try to find all implementations of interfaces. We will then register them all with MEF configuration.

Deployment

Our interface will be called IPlugin and it is actually inherited from IMiddleware . If we wish, we can add more members to it, now it doesn’t really matter:

IMiddleware proposes an InvonkeAsync method that can be called asynchronous and holds the current context and a pointer to the next delegate (or middleware component).

I wrote the extension method below for IApplicationBuilder :

We have defined a convention in which each type is found to implement Iplugin we will register as a share, meaning a singleton form.

As you can see, if the path parameter is not provided, it will default to AppContext.BaseDirectory .

We can add in the plugin / middleware implementation an ExportMetadataAttribute with an Order value specifying the order by which the plugins will load, I’ll explain in detail in a moment.

With the extionsion WithAssembliesInPath method from my previous post but I’ll add it here for you to trust:

If you want to find all assemblies in nested directories, you need to pass SearchOption.AllDirectories as the searchOption parameter, but of course this will have a trade-off if you have multiple subdirectories.

Putting it all together

As such, write a few classes that implement the Iplugin interface and are therefore appropriate to use middleware components:

Notice how we apply an ExportMetadataAttribute to a class with an Order value; This is not necessary and if not provided, it will default to the maximum value of type integer ( int.MaxValue ), meaning it will be loaded after all other plugins. But this class needs to be public and has a public parameters contructor. You can get any of the registered services from the RequestServices property of the HttpContext .

Now, all we need to do is add a pair of assemblies to the bin directory of the web application (or some other path that is passed to UsePlugins ) and call this extension method inside Configue :

And here you have it: ASP.NET Core will find middleware from any assemblies it can find on the path provided.

Conclusion

Middleware is not a new concept, it has been in previous ASP.NET MVC versions, as well as other web programming languages. Here I would like to introduce to us how to register middleware through assemplies (dll files) in ASP.NET Core. This method is fully loaded dynamically with the support of ASP.NET Core. It is very suitable when we attach external plugins to our application. Hope to help you in need of it.

The article is translated from the source:

https://weblogs.asp.net/ricardoperes/dynamically-loading-middleware-in-asp-net-core