LogoAPI Framework is a new open source project (Apache License 2.0) for ASP.NET Core with the aim of bringing more flexibility and more options to building ASP.NET Core based OpenAPI backends. With API Framework your code and your resourcesbecome the OpenAPI endpoints.

With API Framework the endpoints can be build using POCOs, Roslyn Script and Delegates and the reusable APIs can be distributed as plugins using Nuget. The APIs can be added runtime, without having to restart or to rebuild the application. The flexible plugin system with a built-in support for plugins means that API Framework can be used as the secure OpenAPI gateway into other systems. With plugins you can generate OpenAPI endpoints from databases, file systems, Azure blob storage, and more.

API Framework version 1.0.0 is now available from Nuget: https://www.nuget.org/packages/weikio.apiframework.aspnetcore. The project’s home pages is available from https://weik.io/apiframework.

Main Features

“Everything is an OpenAPI” mentality means that there’s multiple ways of building your backend’s endpoints. Plain C# and delegates are supported but so are your database and your browser and many more. Your code and your resources are the OpenAPI endpoints.

You can also integrate API Framework with your existing Controller & Action based app. API Framework is built on top of the MVC-functionality meaning it can take advantage of many of the features provided by ASP.NET Core.

Here’s a short summary of the major features of API Framework:

  • Everything is an OpenAPI:The API can be anything: Database, local files. Even the web browser. APIs can be created with C#, Roslyn Scripts and using delegates. These endpoint provide the full OpenAPI specs, meaning if you have a table called Inventory in your database, your OpenAPI specification will have the same Inventory available for use.
  • Runtime Changes: APIs and endpoints can be configured runtime, when the application is running. No need to restart the system to add a new endpoint.
  • Plugin Support:API Frameworks supports plugins. Nuget.org contains multiple ready made plugins, like SQL Server and Local Files. Custom plugins can be created and shared using Nuget.

There’s many more features, including support for health checks and async JSON streams. More information is available from the project’s home pages.

Terminology & Main Concepts

With API Framework there’s two main concepts:


In API Framework each API has two properties: Name and Version. And the actual functionality they provide.

Most often API is a C# class or a .NET type. But you can also use assemblies, Nuget packages, Roslyn scripts and delegates as APIs. Often the aim is to make APIs reusable and they can be shared using Nuget.


An API itself is not accessible through a web request. That's the work of an Endpoint. Endpoint gives your API a route (for example '/helloworld') and a configuration (if needed).

You can create multiple endpoints from each API and every endpoint can have different configuration.

Quick Start

Here’s a quick start, adapted from the documentation at https://docs.weik.io/apiframework/quickstart.html. The starting point is a blank ASP.NET Core 3.1 web api app.

This quick start shows how to build integration/data hub style backend using API Framework’s plugins. When the quick start is ready, we have an ASP.NET Core based backend which provides access to SQL Server and to an another OpenAPI backend (the PetShop).

In this quick start the APIs and Endpoints are added through code. Configuration through appsettings.json (IConfiguration) and through runtime REST endpoints are also supported.

1. Add the required package for API Framework:

        <PackageReference Include="Weikio.ApiFramework.AspNetCore.StarterKit" Version="1.0.0"/>

2. Add the SQL Server and OpenAPI plugins:

        <PackageReference Include="Weikio.ApiFramework.Plugins.SqlServer" Version="2.0.0" />
        <PackageReference Include="Weikio.ApiFramework.Plugins.OpenApi" Version="1.0.0" />

3. Modify Startup.Configure by adding API Framework & required APIs and Endpoints:

        public void ConfigureServices(IServiceCollection services)

                .AddOpenApi("/pets", new ApiOptions()
                    SpecificationUrl = "https://petstore3.swagger.io/api/v3/openapi.json",
                    ApiUrl = "https://petstore3.swagger.io/api/v3"
                    new SqlServerOptions()
                        // This provides a read only access to the db used in the documentations
                        ConnectionString =
                            "Server=tcp:adafydevtestdb001.database.windows.net,1433;User ID=docs;Password=3h1@*6PXrldU4F95;Integrated Security=false;Initial Catalog=adafyweikiodevtestdb001;"

4. Run the application, wait a few second (the endpoints are generated on the background) and navigate tohttps://localhost:5001/swagger


The SQL Server database can be queried and filtered and the OpenAPI specs contains the schema for the database:


Getting Started

The quick start above show one approach for using API Framework. Best way to learn more about API Framework is through the following resources:

Use Cases

As API Framework adds more flexibility into building and running ASP.NET Core backends, there’s different use cases where it can be helpful:

  • 24/7 Backends:API Framework can be used to create ASP.NET Core backends which can be updated runtime. APIs and endpoints can be added and updated when the system is running. As an example, it’s possible to install API through Nuget and then configure one or more endpoints based on that API. All this runtime.
  • Integration Layers:API Framework can be used as the secure OpenAPI gateway into other systems. With plugins you can generate OpenAPI endpoints from databases, file systems, Azure blob storage, and more. This is helpful in scenarios where you want build integration/data hub style application.
  • More options for building APIs:As mentioned, with API Framework it is possible to build APIs using Roslyn, Delegates and more. This means it is entirely possible to create a backend using a folder of Roslyn Script files.

Current Status

Today is the day of the 1.0.0 release. The work continues, especially with the samples and with documentation. Currently there’s about 12 samples available, showcasing many of the features but there’s more to add. The documentation is little farther behind.

Some of the plugins released today are more advanced than the others. For example the database plugins are quite advanced but something like the Files-plugin is currently very barebones.

Project Home

API Framework can be found from Github and from https://weik.io/ApiFramework.


Starting from this week, Blazor.Animate is proud to be part of the Blazorise. All the updates and future work for Blazor.Animate will continue through Blazorise. For those not familiar with Blazor.Animate, it is an animation component for Blazor. With Blazor.Animate you can animate how other components are brought to the view. You can easily add fade, slide and zoom-effects and even add easing to the animations.

All the updates and future work for Blazor.Animate will continue through Blazorise.

Plugin Framework Logo

New version of Plugin Framework for .NET adds support for reading plugin catalog configuration from appsettings.json and improves plugin tagging. The release is now available through Nuget: https://www.nuget.org/packages/Weikio.PluginFramework/

For those who are not familiar with Plugin Framework, it is a plugin platform for .NET applications, including ASP.NET Core, Blazor, WPF, Windows Forms and Console apps. It is light-weight and easy to integrate and supports multiple different plugin catalogs, including .NET assemblies, Nuget packages and Roslyn scripts.

Here’s an introduction post about Plugin Framework. InfoQ did a an article about the framework, it’s available from their site.

The 1.1.0 release

I’m especially happy with the support for appsettings.json as it’s the first community contribution (thanks @panoukos41 (github.com)!) and as it also enables new scenarios for the framework. Folder and assembly catalogs can be configured with the following syntax (support for more catalog types is coming in the upcoming versions):

  "PluginFramework": {
    "Catalogs": [
        "Type": "Folder",
        "Path": "..\\Shared\\Weikio.PluginFramework.Samples.SharedPlugins\\bin\\debug\\netcoreapp3.1"
        "Type": "Assembly",
        "Path": ".\\bin\\Debug\\netcoreapp3.1\\WebAppPluginsLibrary.dll"

Sample for this specific feature is available from https://github.com/weikio/PluginFramework/tree/master/samples/WebAppWithAppSettings

New version also improves the plugin tagging. The idea behind plugin tagging is that Plugin Framework can for example scan a folder of dlls and tag the found plugins based on the given criteria. The developer can then use the plugins based on their tags. This is useful in situations where the application supports multiple types of plugins.

Here’s an example where all the found plugins are tagged as “operator”:

            var folderPluginCatalog = new FolderPluginCatalog(@"..\..\..\..\Shared\Weikio.PluginFramework.Samples.SharedPlugins\bin\debug\netcoreapp3.1",
                type => { type.Implements<IOperator>().Tag("operator"); });

And another part of the same app tags plugins as “dialog”:

            var folderCatalog = new FolderPluginCatalog(@"..\..\..\..\WinFormsPluginsLibrary\bin\debug\netcoreapp3.1",
                type =>

Now when these plugins are used in the application, they can be fetched using the tags. Here’s an example where the “operator” and “dialog” tags are used:

        private void AddCalculationOperators()
            var allPlugins = _allPlugins.GetByTag("operator");
            foreach (var plugin in allPlugins)

        private void AddDialogs()
            var dialogPlugins = _allPlugins.GetByTag("dialog");
            foreach (var dialogPlugin in dialogPlugins)
                var menuItem = new ToolStripButton(dialogPlugin.Name, null, (o, args) =>
                    var instance = (IDialog) Activator.CreateInstance(dialogPlugin);


Sample for plugin tagging is available from https://github.com/weikio/PluginFramework/tree/master/samples/WinFormsApp

What’s next?

Work will continue on improving (and adding new) plugin catalogs but the main thing for the next release is the support for .NET 5. This will enable one scenario which hasn’t been that well supported: Using Plugin Framework in WebAssembly version of Blazor.

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: https://www.nuget.org/packages/Weikio.PluginFramework/. For Blazor and ASP.NET Core applications the recommended package is https://www.nuget.org/packages/Weikio.PluginFramework.AspNetCore

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: https://github.com/weikio/PluginFramework. 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: https://github.com/weikio/PluginFramework. GitHub also contains the issue tracking.

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


Attach to dotnet.exe extension for Visual Studio 2017 & 2019 now has a new version As the version number indicates, only a small thing has changed: The extension manifest had problems with its dependencies, causing issues when trying to install the extension to VS 2019 Preview.

The new version is now available for download from the project’s repository: https://github.com/mikoskinen/AttachToDotnet/tree/master/releases/

Unfortunately the extension is still not available through the Visual Studio’s extension marketplace, but I hope to have it there in the following week.


Just a quick recap and reasoning for the extension: There’s usually many dotnet.exe processes. Attaching Visual Studio’s debugger to the correct one can be hard. This extensions aims to solve the issue by displaying the actual .DLL of the dotnet.exe process.