ASP.NET Boilerplate: a DDD application framework that reaches end of support in May 2026

The problem ASP.NET Boilerplate targets, and the date that now shapes it

Every line-of-business ASP.NET application rebuilds the same scaffolding: dependency injection wiring, a unit of work around database calls, audit logging, settings, feature flags, background jobs, and tenant isolation. ASP.NET Boilerplate exists to remove that repetition. The README frames it as a general purpose application framework that "automates common software development tasks by convention", so the developer writes business code and the framework supplies the surrounding concerns.

The audience is narrow and identifiable. It is .NET teams building multi-tenant SaaS or internal web applications who accept a prescribed layered structure in exchange for not writing that infrastructure themselves. The repository topics list domain-driven-design, multi-tenancy and nlayer-architecture, and the README links a dedicated NLayer Architecture document. That is a commitment, not a library you drop into an existing controller-heavy codebase.

The date matters more than any feature. The README carries an End of Support Announcement stating that support for ASP.NET Boilerplate officially ends in May 2026, that ASP.NET Zero customers using it will continue to be supported, and that open-source users are directed to migrate to ABP Framework. The last push to the dev branch was on 2026-09-18 and the newest release listed is v10.5 from 2026-07-28, so the code is not frozen, but the published support window is the fact a decision should start from.

Modular design and the unit of work as the actual mechanism

The framework's core mechanism is a module system. Instead of configuring services in one startup file, you declare modules that depend on other modules, and each module registers its own services, entities and configuration. The README describes ABP as "modular and extensible" and says it "provides the infrastructure to build your own modules, too". That is the extension point: third-party or in-house functionality ships as a module that plugs into the same lifecycle rather than as a set of instructions in a wiki.

Around that sits the layered model. The README presents a model based on Domain Driven Design with a SOLID structure, and the repository topics confirm the n-layer intent. The layers are not decorative. Domain logic lives in entities and domain services, application services expose use cases, and the presentation layer stays thin. If your team's instinct is to put queries in controllers, the framework will fight you.

The unit of work is the piece most developers meet first. It wraps a request or an application service call in a transaction and commits or rolls back at the boundary, which is why the search phrase "Asp net boilerplate unit of work" exists at all. Persistence is not locked to one provider: the README lists NuGet packages for Abp.EntityFrameworkCore, Abp.EntityFramework, Abp.NHibernate and Abp.Dapper, plus Abp.FluentMigrator for migrations. Choosing NHibernate or Dapper changes the implementation behind the same abstractions, which is a genuine architectural benefit and also a source of confusion when examples assume EF Core.

Installing ASP.NET Boilerplate and choosing your first packages

ASP.NET Boilerplate is distributed as NuGet packages, and the README points to the project documentation and quick start tutorials for the full setup. The README does not print an install command sequence, and this repository has no template or CLI of its own at the top level, so the honest starting point is the package table plus the documentation link rather than a command copied from a front page that does not contain one.

The core package is Abp. For ASP.NET Core hosting you add Abp.AspNetCore, and for EF Core persistence you add Abp.EntityFrameworkCore; the README lists all three by those exact names. If you use NHibernate, Dapper or Entity Framework 6 instead, the README lists Abp.NHibernate, Abp.Dapper and Abp.EntityFramework as the corresponding packages, and Abp.FluentMigrator for migrations. For tests it lists Abp.TestBase and Abp.AspNetCore.TestBase.

The practical first step is therefore to pick a quick start tutorial from the documentation and let it generate the module skeleton, then add packages from that table as the application needs them. The README does not show the module class body, the DependsOn attribute usage or the service registration call, so anything you see elsewhere with those names should be checked against the Module System document rather than assumed. What you should expect once the skeleton is in place is that your own services resolve from the container without a hand-written registration for each one, which is the convention-based behaviour the README describes.

If you also want the identity, settings, audit log, feature and background job stores, those come from Module Zero, a separate module integrating ASP.NET Identity. The README links its documentation rather than showing the wiring, and that is the point where a generated template saves more time than assembling packages by hand.

Multi-tenancy from database to UI is a design decision, not a toggle

The README markets multi-tenancy as "integrated from database to UI" and describes SaaS applications as made easy. The claim is accurate in scope: tenant resolution, tenant-aware data filtering and per-tenant configuration are framework concerns rather than something you bolt on later. Features and settings can vary per tenant, and the Module Zero description lists a setting store and a feature store among the abstract concepts it implements.

The cost is that multi-tenancy is baked into the shape of your entities and queries. Retrofitting a single-tenant application into this model means revisiting data access, not just adding a column. Teams that need tenant isolation at the infrastructure level, with a separate database per tenant managed outside the application, will find the framework's model either convenient or constraining depending on how much of the resolution logic they want to own. The documentation covers the model; it does not argue for it, and the README gives no guidance on which isolation strategy to pick.

Background jobs, Hangfire and Quartz as separate choices

Background work is one of the framework's abstract concepts, and Module Zero lists a background job store among the implementations it supplies. The store matters because it persists job definitions and state; the runner is a separate decision. The README lists Abp.HangFire and Abp.HangFire.AspNetCore for Hangfire, and Abp.Quartz for Quartz. Both are optional packages, so a project that never schedules work does not carry either dependency.

This split is sensible and also a common source of confusion. If you search for how background jobs work in ABP, you will find answers that assume Hangfire and answers that assume Quartz, and the store behaviour differs depending on which runner you install. The README lists the packages but does not compare the two runners or describe when to prefer one. That comparison lives in the documentation, not in the repository front page.

There is a related constraint worth naming: the background job store is part of Module Zero, which is built on ASP.NET Identity. A project that wants ABP's module system and unit of work but has its own identity solution is not obliged to take Module Zero, and with it the setting, audit log, feature and background job stores. Those are separate concerns that happen to ship together.

Where ASP.NET Boilerplate is the wrong tool

The clearest wrong case is a new project with a multi-year horizon. The README states support officially ends in May 2026 and recommends open-source users migrate to ABP Framework. Starting fresh on a framework whose published support window closes is a decision that needs an explicit justification, and the README does not offer one.

The second case is a small application. The layered model, module system and convention-based registration pay off when an application has many use cases and several teams. For a handful of endpoints over one table, the structure is overhead: more projects, more indirection, and a debugging path that runs through framework code before reaching yours. The README does not discuss this trade-off, and its framing assumes a substantial web application.

The third case is a team that wants to keep ASP.NET MVC 5.x and EF 6.x indefinitely. The README states the framework supports both those and the newer ASP.NET Core and EF Core stacks, which is unusual breadth. But breadth across two generations of the platform also means documentation and examples are split, and a reader following a tutorial has to check which stack it targets before copying anything.

ABP Framework is the named alternative, and the difference is not cosmetic

The README itself names the alternative: for open-source users it recommends migrating to ABP Framework. This is not a competing project with a similar name; it is the successor, and the README points to it in the end of support announcement. The practical difference in approach is that ABP Framework is where ongoing development continues, while ASP.NET Boilerplate receives support for ASP.NET Zero customers through the stated window.

For a team already on ASP.NET Boilerplate, that framing changes the migration question from "should we switch stacks" to "when do we move to the successor". The README does not document a migration path, and it does not describe how much of an existing application carries over. Anyone planning that move should treat the end of support announcement as the starting document, not this repository's front page.

For a team not yet committed, the comparison is simpler: adopting ASP.NET Boilerplate today means adopting a framework that the README says is ending support, when the recommended destination is available. The only reasons to pick the older one are an existing codebase, an ASP.NET Zero relationship, or a specific dependency on the MVC 5.x and EF 6.x support that the README advertises.

Licence, upgrade cost and what the repository does not say

The repository is licensed under MIT, per the LICENSE.md file at the top level. MIT is permissive: it allows commercial use, modification and redistribution with the licence and copyright notice retained. That is a fact about the licence text, not advice about your situation, and the README adds a commercial dimension by stating that ASP.NET Zero customers using ASP.NET Boilerplate will continue to be supported after the general end date. Support terms for that product are governed by its own terms, not by the MIT grant.

Upgrade cost is visible in the release cadence. The listed releases are v10.3 on 2025-08-21, v10.4 on 2026-04-28 and v10.5 on 2026-07-28, with the dev branch last pushed on 2026-09-18. That is a regular cadence, and it also means version-to-version upgrades are a recurring task rather than a one-time setup. The repository ships build scripts (build.cmd, build.ps1, build.sh), a global.json pinning the SDK, and a version-update.ps1, which tells you the maintainers build and version the framework through their own tooling. A consuming application does not inherit that; it inherits whatever the NuGet packages require.

What the repository front page does not state is equally relevant. The README does not document a rollback procedure for upgrades, does not describe how long each release line is supported, and does not give a migration guide to ABP Framework. Those gaps are why the end of support announcement, linked from the README, is the document to read before planning anything.

Editorial conclusion

ASP.NET Boilerplate still fits teams maintaining an existing ABP-based application on ASP.NET Core or ASP.NET MVC 5.x, and teams that need the Module Zero pieces (setting store, audit log store, background job store, feature store) already wired to ASP.NET Identity. It does not fit greenfield projects that expect support past May 2026, because the README states support officially ends then and points open-source users to ABP Framework. Before committing, check the end of support announcement on aspnetboilerplate.com, confirm which NuGet packages your solution already references (Abp, Abp.AspNetCore, Abp.EntityFrameworkCore, Abp.TestBase), and verify the Module Zero store implementations against your persistence choice.

Frequently asked questions

Official sources

1. aspnetboilerplate/aspnetboilerplate on GitHub
2. License: MIT
3. Project website
4. README
5. Releases