Plugin Framework Logo

Plugin Framework is a new MIT-licensed plugin platform for .NET Core applications. It is light-weight and easy way to add a plugin-support into your application. It supports all the major types of .NET Core applications, including ASP.NET Core, Blazor, Console Apps and WPF & WinForms.Plugin Framework has a built-in support for Nuget packages and feeds.

The Plugin Framework version 1.0.0 is now available from Nuget: For Blazor and ASP.NET Core applications the recommended package is

Main features

Plugin Framework follows an "Everything is a plugin" -mentality. It provides out of the box support for sharing plugins using Nuget packages, Roslyn scripts and delegates, in addition to the more common ones like .NET assemblies and folders.

Here’s a short summary of the major features provided by Plugin Framework:

  • Deliver plugins as Nuget-packages, .NET assemblies, Roslyn scripts and more.
  • Easy integration into a new or an existing .NET Core application.
  • Automatic dependency management.
  • MIT-licensed, commercial support available.

Quick start: ASP.NET Core

Install-Package Weikio.PluginFramework.AspNetCore

Using Plugin Framework can be as easy as adding a single new line into ConfigureServices. The following code finds all the plugins (types that implement the custom IOperator-interface) from the myplugins-folder.


The plugins can be used in a controller using constructor injection:

public CalculatorController(IEnumerable<IOperator> operator)
	_operators = operators;

Getting started

Best way to learn more about Plugin Framework is through the project's home page at Github: The repository contains multiple different samples at the time of writing this. Here's a list:

Plugin Framework & .NET Console Application
Plugin Framework & ASP.NET Core
Plugin Framework & Blazor
Plugin Framework & WPF App
Nuget & Plugin Framework & ASP.NET Core
Roslyn & Plugin Framework & ASP.NET Core
Delegates & Plugin Framework & ASP.NET Core

How does this work?

When you create your application and add support for Plugin Framework, you usually define two things:

1. The specifications for the plugins. In some applications a plugin can add new functionality into the UI. In other apps, plugins are used to distribute logs into multiple different systems. The application defines what kind of extensions it supports.

2. The locations where the application can find the plugins. Many applications use a specific “plugins”-folder to indicate the location where plugins should exist in the hard drive. In some situations plugins are installed in runtime from Nuget. These plugin locations are called catalogs. As a developer you define what catalogs your application uses.

What makes a plugin?

In the context of the Plugin Framework, plugin is a single .NET Type. For some applications a plugin is a type which implements a specific interface. In some applications a plugin is a type which has a single public method called Run. Attributes are often used to indicate the plugins and that is also supported by Plugin Framework. From the Plugin Framework's point of view anything or everything can be a plugin.

What is a plugin catalog?

Each plugin is part of a catalog. Plugin Framework provides the following officially supported catalogs:

  • Type
  • Assembly
  • Folder
  • Delegate
  • Roslyn script
  • Nuget package
  • Nuget feed

License & Source code & Commercial Support & Issue Tracking

As previously mentioned, Plugin Framework is MIT-licensed and its source code is available from GitHub: GitHub also contains the issue tracking.

There is also commercial support available for Plugin Framework. That is provided by Adafy Though the website is only in Finnish, the support is available both in English and in Finnish.


Null conditional operator allows us to write more terse code. And unfortunately, more subtle bugs. The combination of Null Conditional Operator with Any() is easily my current favourite for The Winner of 2019’s Most Bugs Caused by a New C# Feature.

Combining Null Conditional Operator ?. with System.Linq.Enumerable.Any allows us to quickly check if our collection is not null AND not empty. So instead of writing this:

        public static void DoWork(List myWorkItems)
            if (myWorkItems != null && myWorkItems.Any())
                Console.WriteLine("Doing work");

            Console.WriteLine("Nothing to do");

We can use Null Conditional Operator and save few key strokes:

        public static void DoWork(List myWorkItems)
            if (myWorkItems?.Any() == true)
                Console.WriteLine("Doing work");

            Console.WriteLine("Nothing to do");

Maybe we could make the code even better, by reducing nesting by inverting the if:

        public static void DoWork(List myWorkItems)
            if (myWorkItems?.Any() == false)
                Console.WriteLine("Nothing to do");

            Console.WriteLine("Doing work");

Ah, no. Did you spot the bug?


If we expand the example, we get a better picture of the situation:


Why this happens? Because myWorkItems?.Any() doesn’t return false when the collection is null. It returns Nullable Boolean instead:


Getting around the issue is quite simple: Instead of checking for == false, we check for != true:

            if (myWorkItems?.Any() != true)
                Console.WriteLine("Nothing to do");

But do we always remember this? Based on the code I’ve seen this year the answer is quite simply no.

Maybe there’s a Roslyn Analyzer for spotting this automatically?


GrazeDocs is a new open source static documentation site generator. GrazeDocs converts your Markdown files into full-blown static HTML-pages which you can host anywhere. GrazeDocs uses Razor for themes and it is available as a .NET Core Global Tool.

Project home site:

Project repository:


Here’s a list of few interesting features provided by GrazeDocs:

  • Clean and light default theme
  • Automatically generated table of contents
  • Live preview

Live previews is one of the standout features: Live Preview automatically opens a browser with your published documentation site. Every time you update the documentation, the site is automatically updated. You don’t have to manually publish your site to make sure your site looks correct. The Live Preview is done using SignalR.

Getting started

GrazeDocs aims to make it easy to get started by using conventions but it also tries to offer customization options if you aren’t happy with the defaults. For more thorough guides, please visit the documentation available at or the samples at

GrazeDocs is available as a global tool for .NET Core. To install:

dotnet tool install -g GrazeDocs

To start creating your documentation, use GrazeDocs -i . to initialize documentation into the current folder:

GrazeDocs -i .

After your happy with the documentation, use GrazeDocs -p to publish your complete site:

GrazeDocs –p

Examples and more information

GrazeDocs home page is created using GrazeDocs. You can find the site’s source code from

For more information, GrazeDocs samples are good starting point as is


Alias engine is a new MIT-licensed open source C# & .NET Standard based engine for creating aliases for your commands. It's inspired by the alias support which mIRC provides.

Example: Alias “ae” can be used to execute command “Alias Engine”.

The project can be found from GitHub and the engine is available through Nuget


What is an alias and what you can do with them? Aliases can be used to shorten commands. If your application provides a “help” command, you can provide a shorter alias “h” for running it.

Alias Engine can also be used to provide alias feature for the end user. Your application can provide a fixed set of commands like “help”, “show”, “create” and the user of your application can create aliases for executing the commands.


Alias Engine supports these features:

  • Multi-Command aliases
  • Multi-Parameter aliases
  • Multi-Word parameters

Here’s a quick example of using the engine:

var converter =new AliasConverter(new InMemoryAliasStore(),new NullLogger<AliasConverter>());
converter.AddAlias("/x multiple return words");
converter.AddAlias("/j /join {0}");
[TestCase("/x", ExpectedResult ="multiple return words")]
public string CanRunAlias(string alias)
var result = converter.Convert(alias);
return result[0];
[TestCase("/j hello", ExpectedResult ="/join hello")]
public string CanRunAliasWithParameters(string alias)
var result = _converter.Convert(alias);
return result[0];

For more examples, the best place is to check Alias Engine tests:


I’ve released a new open source extension for Visual Studio 2017&2019 which aims to make it easier to attach and to reattach the Visual Studio debugger to the correct dotnet.exe process:

With the default “Attach to process” –feature in Visual Studio it’s often hard to know what is the correct dotnet.exe to debug. Without the extension the visibility to dotnet.exe process is often this:

The extension aims to solve this issue by parsing the actual application from the process’ command line. In addition to displaying and attaching to a particular project, the extension provides “Reattach to dotnet.exe” command. This functionality works even if the process id changes (as it does when using dotnet watch).

Default shortcuts: 

  • Reattach: CTRL + Shift + Del
  • Attach: Shift + Del

Note: For now the extension has been mainly tested with ASP.NET Core 2.0 based applications. Later versions of ASP.NET Core and .NET Core may change things so it’s possible that the extension displays these processes incorrectly.

The extension is not yetavailable from Visual Studio Marketplace but I hope to see it there shortly. But you can download and install it from here:

The source code for the extension is available through Github: