# OSharp: an ASP.NET Core scaffolding framework for .NET 6 business applications

> OSharp wraps ASP.NET Core configuration, DI, logging, caching, EF Core, WebApi, authentication and permission handling into a fixed business code structure. It targets .NET teams that want a pre-shaped application skeleton, not a library you drop into an existing codebase.

**dotnetcore/osharp** — OSharp是一个基于.Net6.0的快速开发框架，框架对 AspNetCore 的配置、依赖注入、日志、缓存、实体框架、Mvc(WebApi)、身份认证、功能权限、数据权限等模块进行更高一级的自动化封装，并规范了一套业务实现的代码结构与操作流程，使 .Net  框架更易于应用到实际项目开发中。

- Repository: https://github.com/dotnetcore/osharp
- Website: https://demo.osharp.top/
- Stars: 2,848 · Forks: 763
- Language: C#
- License: Apache-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/dotnetcore-osharp

## What OSharp is for, and who it is not for

OSharp is a .NET 6 rapid development framework. The README describes it as wrapping ASP.NET Core's configuration, dependency injection, logging, caching, Entity Framework, MVC/WebApi, authentication and permission modules at a higher level of automation, and as standardising a code structure and operating flow for business implementation. Read that sentence carefully: the value proposition is not a single feature but a prescribed shape. The framework tells you where entities go, where entity configuration goes, where services go, and where the WebApi layer sits.

That makes it a poor fit for an existing solution. If you already have a working ASP.NET Core application with its own layering, adopting OSharp means adopting its conventions across the project, not adding one package. The repository layout supports this reading: alongside src/ there is a samples/ directory with web/ and wpf/ subdirectories, and the README lists separate hosting projects (OSharp.Hosting.Core, OSharp.Hosting.EntityConfiguration, OSharp.Hosting.Apis) that carry the non-business modules such as authentication, permissions, system and messaging. Those are the pieces you would otherwise write yourself.

The intended user is a team starting a business application that needs accounts, roles, function permissions and data permissions on day one. The README also points to UI starters: a Vue version, an Mvc version built on layui, and an Angular version using ng-alain. Those are separate repositories or branches, not part of the core package set, so treat the front end as a decision you make independently.

## How the component set is split across NuGet packages

OSharp is not one assembly. The README enumerates the components, and the split is the most useful thing to understand before you commit. OSharp itself is the core: utility helpers, core interfaces for each component, and some core implementations. OSharp.AspNetCore adds the server-side wrapping. On top of that sit optional concerns, each its own package: OSharp.AutoMapper for object mapping, OSharp.Swagger for API test pages, OSharp.Log4Net and OSharp.NLog for logging, OSharp.Redis for distributed cache, OSharp.MiniProfiler for performance monitoring, OSharp.Hangfire for background jobs, OSharp.Identity for ASP.NET Core Identity based authentication, and OSharp.IdentityServer for IdentityServer4 based authentication and client authorisation.

Data access is split by provider. There is OSharp.EntityFrameworkCore for the EF Core wrapper, and then one package each for MySql, SqlServer, Sqlite, PostgreSql and Oracle. If your database is not among those, the framework does not ship a provider for it, and the README does not describe an extension point for adding one. That is a real boundary, not a footnote.

The permission model is split in two as well, and this is the part that distinguishes OSharp from a generic template. OSharp.Authorization.Functions handles API function permission authorisation. OSharp.Authorization.Datas handles data permission authorisation, meaning which rows a given user may reach. Most scaffolding frameworks stop at the first. The README states the second exists and describes it as a design and implementation for authorising data permissions in an application, but it does not document the rule syntax or the evaluation flow, so plan to read the source.

One maintenance point: the README's own NuGet table lists OSharp.Utils, OSharp.Core, OSharp.AspNetCore, OSharp.Authorization.Datas, OSharp.Authorization.Functions and OSharp.AutoMapper, and the text is truncated there. The table is not a complete index of the packages named in the component list. Verify each package id on nuget.org rather than trusting the list alone.

## Installing OSharp and getting a first WebApi call to respond

The README does not contain a step-by-step install section. It points to a documentation site at docs.osharp.org, a demo at demo.osharp.top, a Visual Studio code generator extension published as LiuliuSoft.osharp, and the samples/ directory in the repository. So the honest first step is not a command, it is a choice: either clone the repository and open osharp.sln to read a working host, or start from the documentation site.

If you want to pull the core packages into a project you control, the package ids come from the README's table. A minimal set for a server application would be the core plus the ASP.NET Core wrapper plus one EF Core provider. The provider package names follow the pattern shown in the component list, for example OSharp.EntityFrameworkCore.SqlServer.

```bash
dotnet add package OSharp.Core
dotnet add package OSharp.AspNetCore
dotnet add package OSharp.EntityFrameworkCore.SqlServer
```

The repository pins its SDK expectations in a global.json at the top level, and the solution file is osharp.sln. If you clone instead of installing packages, that is where you start.

```bash
git clone https://github.com/dotnetcore/osharp.git
cd osharp
dotnet build osharp.sln
```

What you should see after the build is the framework and its test projects compiling. The samples directory holds the runnable hosts, with samples/web/ and samples/wpf/ as the two top-level sample entries. The README does not give the command to launch a sample host, and it does not list a default port, so read the sample's own configuration rather than assuming one. That gap is worth noting: a framework that prescribes project structure should document the first run, and this README does not.

## The release cadence does not match the commit activity

The repository is not archived, and its last push was on 2026-09-22, which is recent. But the most recent release listed is 7.0.11-snow (tagged v7.0.11) from 2023-10-02. Before that, v6.0.4 dates from 2022-04-30 and v6.0.0 from 2021-12-28. So the commits are current while the tagged releases are roughly three years old relative to the last push.

For an adopter this matters more than the commit graph. If you consume OSharp through NuGet, the version you get is the released one, not master. The README does not explain the gap, and it does not document a versioning or support policy for the packages. There is no statement about which .NET versions are supported beyond the .NET 6.0+ claim in the introduction, and no deprecation notice for the older release lines.

There is a second signal in the same area. The README's badge section links a NuGet badge for OSharp.Core to the page for osharpns, and the licence badge points at a LICENSE file in a different repository path (i66soft/osharp-ns20) than the one this repository carries. Those are documentation inconsistencies, not functional defects, but they are the kind of thing that costs an afternoon when you are trying to confirm what you are installing. Treat the repository's own LICENSE file and the nuget.org package page as the authority.

## Where OSharp is the wrong tool

The clearest failure case is an existing application. OSharp's permission modules assume the framework's own user, role and function entities. The README describes OSharp.Hosting.Core as implementing the non-business modules including authentication, permissions, system and messaging, and OSharp.Hosting.EntityConfiguration as mapping those entities. If your application already has a user table and an authorisation scheme, you are either migrating to OSharp's model or running two models side by side. Neither is cheap, and the README does not describe an adapter for bringing your own identity store.

Database support is the second hard boundary. Five EF Core providers are listed. Anything else is unsupported by the shipped packages.

The third case is a team that wants to pick its own libraries. OSharp bundles decisions: AutoMapper for mapping, Log4Net or NLog for logging, Redis for distributed cache, Hangfire for background jobs, IdentityServer4 for the token server. Each is a separate package, so you can leave some out, but the framework's own hosting modules are written against them. Swapping AutoMapper for something else means replacing more than a registration line.

Finally, consider the documentation surface. The README is a component inventory and a set of links. The install path, the first run, the data permission rule format and the upgrade policy all live on docs.osharp.org or in the source. If your team cannot spend the time reading C# to learn a framework, the README alone will not get you to a running application.

## How OSharp differs from ABP Framework

The obvious comparison for a .NET team evaluating OSharp is ABP Framework, which occupies the same space: a full application framework with modules, permissions, a data access layer and a UI story. The difference in approach is scope and opinionation. ABP is built around a module system where you compose features and can replace individual pieces, and it publishes a large set of pre-built modules. OSharp's unit of composition is the layer: core, ASP.NET Core, entity framework, permissions, hosting. You take the layers.

A second difference is the permission split. OSharp separates function permission (which API may be called) from data permission (which rows are visible) into two packages, OSharp.Authorization.Functions and OSharp.Authorization.Datas. ABP's permission system is primarily about the first, with data filtering handled through other mechanisms. If row-level authorisation is a first-class requirement in your project, OSharp's explicit split is worth examining on that basis alone.

The third difference is the release rhythm. ABP ships on a regular cadence with documented versioning. OSharp's latest listed release is from 2023-10-02 while the repository's last push is 2026-09-22, and the README states no support policy. That asymmetry should weigh in the decision, particularly for a team that needs to plan upgrades.

## Licence, upgrade cost and what to check before adopting

OSharp is licensed under Apache-2.0, per the repository metadata and the licence badge in the README. Apache-2.0 is a permissive licence that includes an express patent grant and permits commercial use. It also requires that you preserve copyright and licence notices and state significant changes when you redistribute. This is a description of the licence text, not legal advice; if your organisation has a licence review process, run the repository's LICENSE file through it, and note the README badge points at a different repository's licence path, so use the file in this repository.

Upgrade cost is the harder question. The framework tracks .NET versions: the introduction says .NET 6.0+, and the default branch is named master while the samples reference a net6 branch path in the Angular sample link. Moving from one framework major version to the next means moving your project structure with it, because the framework owns the layering. The README does not document a migration guide, and the release list shows only three tagged releases, so there is little published history to reason from.

Before you commit, three checks. First, confirm every package id you intend to use on nuget.org, because the README's table is partial and its badge links are inconsistent. Second, confirm a provider package exists for your database among MySql, SqlServer, Sqlite, PostgreSql and Oracle. Third, open samples/web/ and build it, so you see the structure you are agreeing to before you write business code inside it.

## Conclusion

Adopt OSharp if you are starting a new .NET 6 business application and want function permissions, data permissions, EF Core providers and a WebApi layer already wired into one structure. Do not adopt it if you need a small library inside an existing solution, if you depend on a release cadence, or if you cannot accept a NuGet package that the README's own table does not list. Before committing, verify the package ids you intend to install on nuget.org, confirm the provider packages for your database exist, and check the samples directory for a runnable host that matches your target .NET version.

## FAQ

### What database providers does OSharp support?

The README lists EF Core provider packages for MySql, SqlServer, Sqlite, PostgreSql and Oracle. There is no provider for other databases, and the README does not describe an extension point for adding one. You would need to write that integration yourself.

### Is OSharp actively maintained?

The repository is not archived and its last push was on 2026-09-22. The most recent release listed is 7.0.11-snow from 2023-10-02, so commits and tagged releases are on different timelines. The README does not state a support or versioning policy.

### What is the difference between function permissions and data permissions in OSharp?

They are two separate packages. OSharp.Authorization.Functions covers API function permission authorisation, and OSharp.Authorization.Datas covers data permission authorisation. The README names both but does not document the data permission rule format, so that detail has to come from the source or the documentation site.

### What licence does OSharp use?

The repository is licensed under Apache-2.0. That is a permissive licence allowing commercial use, with requirements to preserve notices and state significant changes on redistribution. Check the LICENSE file in this repository, since the README's badge points at a licence in a different repository path.

## Sources

- [dotnetcore/osharp on GitHub](https://github.com/dotnetcore/osharp)
- [License: Apache-2.0](https://github.com/dotnetcore/osharp/blob/master/LICENSE)
- [Project website](https://demo.osharp.top/)
- [README](https://github.com/dotnetcore/osharp/blob/master/README.md)
- [Releases](https://github.com/dotnetcore/osharp/releases)

---

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