Plugin architecture with ASP.NET Core and Autofac

Plugin architecture with ASP.NET Core and Autofac

The plugin architecture is definitely the trickiest part of TeamScreen yet. I encountered many problems during its creation and needed to compromise on few things. Treat this article more like proof of concept rather than the fully-mature solution – it works, but I believe it could be done better. If you have better idea, please share it in comments – I’m always open to constructive feedback 🙂

The requirements for the architecture are – the plugin itself is packed in a DLL file or something similar, after copying it to the main TeamScreen directory and application restart – it’s recognized and can be used. TeamScreen provides only main structure for the plugin, which allows for a great degree of freedom when developing it.

I started work by moving all of the TeamCity logic to another repository. Most of it started working from the get go. The main issue I haven’t been able to handle yet is the lack of intellisense and false-positive errors on cshtml plugin’s view. When the application is run everything works just fine, that’s why I mentioned false-positive errors. Even stack-overflow haven’t been able to help me. Apart from that – it works.

Views are now set as an embedded resource, so they’re attached to DLL file – one less thing to copy 🙂 To allow ASP.NET Core to find such views I needed to set it up in Startup class:

To find plugin assemblies I use this code:

I search the current directory for DLL files which names starts with TeamScreen.Plugin. I omit TeamScreen.Plugin.Base.dll, because it’s assembly containing base types for plugins. Next, I load assemblies. It must be done this way, loading using AssemblyName doesn’t work for some reason.

TeamScreen.Plugin.Base project serves as a base project for all Plugins. Right now, the most important part of it is IPlugin interface:

I believe it’s self-explanatory, every plugin needs to provide its name, URL to view and URL to settings view, for TeamCity plugin it is:

With the creation of plugin architecture, built-in Dependency Injection container wasn’t sufficient – I changed it to the Autofac, which is one of the most popular DI containers in the .NET world. I used it with success in many projects in past. What I needed from Autofac are two features – modules and multiple implementations of a single interface. Modules allow you to separate registrations to different classes and even different assemblies. Module for TeamCity plugin:

All plugins will implement IPlugin interface, basing on that and using Autofac ability to resolve such interface I can easily get a list of all plugins in the system, which is the job of PluginService:

By using parameter IEnumerable<IPlugin> I tell Autofac to resolve all classes that implement IPlugin interface. During registration we must additional use method PreserveExistingDefaults, otherwise, next registration will overwrite previous one. Usage in TeamCityModule:

I also created PluginController, which uses PluginService to deliver information about plugins on UI:

The code is I believe straight-forward, I only needed in GetPluginsEndpoints method to add core settings for TeamScreen itself.

UI created in previous posts was also needed to be altered to take into account, plugin list can be dynamic. Container view for displaying plugins:

Settings view for displaying all settings:

With all that code, the application is now much more flexible. There is still a lot of work – I created mostly frame for future, but it is something that needed to be done. Thank you for reading and hope to see you next time 🙂

3 thoughts on “Plugin architecture with ASP.NET Core and Autofac

  1. Pingback:
  2. Hi, did you put this project on GitHub? I couldn’t find any info about that in your posts.

Leave a Reply

Your email address will not be published. Required fields are marked *