# PluginCore adds hot swappable plugins to an ASP.NET Core application

> PluginCore is an ASP.NET Core plugin framework that loads, enables, disables and uninstalls plugins at runtime, gives each plugin its own controllers and routing, supports dependency injection into plugin classes, ships a JavaScript SDK and a Vue admin front end, and needs no database. It suits a team that must extend a running application without redeploying it, and it is a Chinese language project with a thin public API surface.

**yiyungent/PluginCore** — 🔌 ASP.NET Core lightweight plugin framework | ASP.NET Core 轻量级 插件框架 - 一分钟集成 | Vue.js frontend | JavaScript SDK

- Repository: https://github.com/yiyungent/PluginCore
- Website: https://yiyungent.github.io/PluginCore/
- Stars: 529 · Forks: 109
- Language: C#
- License: LGPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/yiyungent-plugincore

## What problem the framework is solving

PluginCore is described as an ASP.NET Core lightweight plugin framework, with a one minute integration pitch, a Vue.js front end and a JavaScript SDK. The problem it addresses is the one every ASP.NET Core team eventually hits: the application is deployed, and now somebody needs a new feature without a rebuild and a redeploy window. The feature list answers that directly. Each plugin can add a Controller and have its own routing. You can upload, install, enable, disable, uninstall and delete without restarting the site, and you can even add the HTTP request pipeline middleware at runtime through the plugin, with no need to restart the site. The front and back ends of a plugin are separated, so you can place the front end files such as index.html under the plugin's wwwroot folder and then visit /plugins/pluginId/index.html. The stated principles are simple, out of the box, and near zero intrusion, and the README describes the design goal as agreement rather than configuration, with minimal configuration so you can focus on your business. The project is LGPL-3.0 licensed, the default branch is main, and the last push was on 2026-05-03. The releases are PluginCore.AspNetCore 1.4.3 from 2024-08-31 and 1.4.2 from 2024-04-06, alongside the core package PluginCore 2.2.5 from the same April 2024 date.

## Isolation, sharing and the dependency tree

The two ideas that make plugin hosting hard are isolation and ordering, and the feature list claims both. Plugin isolation and type sharing is listed as perfect isolation with type sharing, which is the difficult combination: plugins should not see each other's types by accident, but they should be able to exchange data through agreed contracts. The mechanism behind it in the repository is a plugin dependency tree with declarative dependencies, so the correct loading order is established automatically from the relationships between plugins rather than from hand written ordering in your startup code. On the programming model side, dependency injection is available in the constructor of the plugin class that implements IPlugin, and the same is true of a controller construction method inside a plugin, so a plugin is an ordinary object graph participant rather than something the framework constructs by reflection and hands raw arguments to. The modularity claim is that the process is modularised, dependency injection is full, and the mechanism can be customised by replacement, which is what tells you the framework is meant to be extended rather than merely used.

## Installing the package and wiring it into Startup

The recommended route is NuGet, and the README asks you to run the command in the root directory of your project or in the NuGet Package Manager console with the default project set to the one you want.

```bash
PM> Install-Package PluginCore.AspNetCore
```

The integration itself is two calls, one in the service registration and one in the request pipeline.

```C#
using PluginCore.AspNetCore.Extensions;

// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();

    // 1. Add PluginCore
    services.AddPluginCore();
}

// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseHttpsRedirection();

    app.UseRouting();

    // 2. Use PluginCore
    app.UsePluginCore();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}
```

You then visit the PluginCore Admin path to reach the administration interface, with the port in the example being whatever your own application uses rather than the one in the documentation.

## The admin front end and the default credentials

Once installed, the admin interface is reached under /PluginCore/Admin, and the README instructs you to log in and, for safety, change the default user name and password in time. The configuration lives in App_Data/PluginCore.Config.json.

```json
{
	"Admin": {
		"UserName": "admin",
		"Password": "ABC12345"
	},
	"FrontendMode": "LocalEmbedded",
	"RemoteFrontend": "https://cdn.jsdelivr.net/gh/yiyungent/plugincore-admin-frontend@0.1.2/dist-cdn"
}
```

Two things about that file deserve attention. The credentials are a published default, and the admin surface exposes plugin installation, which means anyone who can reach it with those credentials can run code in your application, so this file is the first thing to change on any machine that is not a developer laptop. The second is the FrontendMode of LocalEmbedded against a RemoteFrontend pointing at a jsDelivr URL for the plugincore-admin-frontend project at version 0.1.2. The framework can either serve the admin interface from local embedded assets or pull it from that CDN address, which is a choice about whether your admin panel depends on a third party being reachable at the moment you install a plugin. The README also states that after the modification it takes effect immediately with no need to restart the site, and that you need to log in again.

## Running it under Docker to try it out

The README suggests trying the framework locally before integrating it properly, and gives a single container command. The example directory in the repository holds working projects for ASP.NET Core 3.1, ASP.NET Core 5, ASP.NET Core 6, and a variant that includes Natasha.

```bash
docker run -d -p 5004:80 -e ASPNETCORE_URLS="http://*:80" --name plugincore-aspnetcore3-1 yiyungent/plugincore-aspnetcore3-1
```

After that you visit the admin path on the published port. For a fuller deployment the README points at the docker-compose.yml in the repository root, and that file shows the production shape more clearly than the one-liner does. It defines a single service built from the same image, publishes host port 5007 to container port 80, restarts always, sets the timezone to Asia/Shanghai and the environment to Production, and passes ASPNETCORE_URLS as an unquoted http://*:80 value, with a comment warning against quoting it. It then mounts four host directories into the container: Plugins and App_Data under /app, PluginCoreAdmin under /app/PluginCoreAdmin, and Plugins_wwwroot under /app/Plugins_wwwroot. Those mounts are the part worth noting, because they are what makes plugins survive a container restart, and they separate plugin binaries, plugin data, admin assets and plugin front end files into four independently managed directories.

## Widgets, the JavaScript SDK and internationalisation

The front end story is where this framework is more than a loader. Widgets are extension points buried in your front end into which plugins inject content, with HTML, CSS and JavaScript support and event dispatch, which is the mechanism that lets a plugin add a piece of interface without editing the host application's views. The repository contains plugincore-js-sdk for the browser side and plugincore-admin-frontend for the admin interface, alongside a Vue based front end stack of Vue.js, vue-i18n, Vue Router, Vuex and Element UI, with babel, mockjs, sass, autoprefixer, eslint and axios on the build side. The SDK is also a contract: the README says you can write your own plugin SDK, reference it, and write extension plugins with custom plugin hooks, so a team that wants a different integration shape is expected to replace rather than work around. Globalisation comes through an i18n implementation that provides multi-language switching support, which for a framework hosting third party plugins matters, since the plugin and the host rarely share a language. There is also no database dependency, which removes the usual requirement to provision schema for plugin state.

## Where PluginCore is the wrong choice

Four limits are worth stating. The first is the cost of a plugin host. The framework's own claim of near zero intrusion is about the two calls in Startup.cs, but the operational surface is larger: an admin surface with credentials to manage, a Plugins directory to back up, a PluginCore.Config.json that ships with published default credentials, and a plugin lifecycle with enable, disable, uninstall and delete states that your operations runbook now has to cover. For an application that needs three optional feature flags, that is more machinery than the problem deserves. The second is the release rhythm. The ASP.NET Core package releases are from 2024, with 1.4.3 dated 2024-08-31, and the core package 2.2.5 from 2024-04-06, while the last push to the repository was on 2026-05-03, so a project has to establish for itself whether the recent commits are maintenance or the start of a new line. The third is the framework version spread. The examples cover ASP.NET Core 3.1, 5 and 6, and the NuGet package is not versioned to the .NET release it targets, so the .NET version you run and the framework version the plugin host expects are two separate decisions, and the readme does not state which target frameworks the current package supports. The fourth is the supply chain of the admin interface. With FrontendMode set to LocalEmbedded the assets ship with the package, but the RemoteFrontend option points at a specific version of a separate GitHub repository served over a CDN, so an installation that pulls the admin front end remotely depends on that pinned artefact remaining available. The realistic alternative to weigh is the built-in ASP.NET Core extensibility points: assembly discovery with dependency injection, hosted services for background work, and a feature flag mechanism, which cover a good share of what plugin hot swapping buys without a plugin host, an admin panel or a runtime code execution surface.

## Conclusion

Adopt PluginCore if you maintain an ASP.NET Core application that third parties or operators need to extend after deployment, because the framework adds plugin hosting, per plugin routing and a runtime admin surface without requiring a database or a rebuild. Do not adopt it if your plugin needs are modest, because the alternative of a documented HTTP endpoint and a feature flag table in your own code is cheaper than a plugin host, and do not adopt it if your team does not read Chinese, since the documentation is primarily in that language. Verify two things before you commit: which target framework the ASP.NET Core package supports, since the examples cover 3.1, 5 and 6 and the package releases are from 2024, and that you change the default administrator credentials in App_Data/PluginCore.Config.json before the site is exposed, because the shipped default is admin with the password ABC12345. The practical first step is to install the PluginCore.AspNetCore package, add the two calls to ConfigureServices and Configure, and open /PluginCore/Admin on a local machine to confirm the admin surface loads.

## FAQ

### What is PluginCore?

It is a lightweight ASP.NET Core plugin framework written in C#, with a Vue.js front end and a JavaScript SDK, that lets plugins be uploaded, installed, enabled, disabled and uninstalled at runtime without restarting the site. It is licensed LGPL-3.0 and requires no database.

### How do I install PluginCore in an ASP.NET Core project?

Install the NuGet package with Install-Package PluginCore.AspNetCore, add services.AddPluginCore() in ConfigureServices and app.UsePluginCore() in Configure, then open the PluginCore Admin path. The README frames the whole integration as two lines of code.

### What are the default PluginCore admin credentials?

They are configured in App_Data/PluginCore.Config.json and the shipped values are the user name admin and the password ABC12345. The README asks you to modify the default user name and password in time for safety, and the change takes effect immediately without a restart.

### Does PluginCore need a database?

No. The feature list states no database required and no database dependency. The only third-party package it relies on is SharpZipLib, used for decompression.

### How do plugins get their own routes and dependencies?

Each plugin can add a Controller and have its own routing, dependency injection is available in the constructor of a plugin class implementing IPlugin and in controller constructors, and plugins declare their dependencies so the framework establishes the correct loading order automatically from the dependency tree.

## Sources

- [License: LGPL-3.0](https://github.com/yiyungent/PluginCore/blob/main/LICENSE)
- [Project website](https://yiyungent.github.io/PluginCore/)
- [README](https://github.com/yiyungent/PluginCore/blob/main/README.md)
- [Releases](https://github.com/yiyungent/PluginCore/releases)
- [yiyungent/PluginCore on GitHub](https://github.com/yiyungent/PluginCore)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/yiyungent-plugincore