Dotnet-Boxed Framework: small NuGet packages that fill the ASP.NET Core gaps

Five packages that can be taken one at a time

The project describes itself as .NET Core Extensions and Helper NuGet packages, and the packaging decision is the first thing to understand about it. There are five published packages, and each is a separate NuGet dependency rather than one umbrella library.

Boxed.Mapping sits on its own, with its documentation at ./Documentation/Boxed.Mapping.md. Boxed.AspNetCore is the larger web oriented package, documented at ./Documentation/Boxed.AspNetCore.md. Boxed.AspNetCore.Swagger is broken out at ./Documentation/Boxed.AspNetCore.Swagger.md, and Boxed.AspNetCore.TagHelpers at ./Documentation/Boxed.AspNetCore.TagHelpers.md, which is the one the repository topics name as taghelpers. The fifth is Boxed.DotnetNewTest, documented at ./Documentation/Boxed.DotnetNewTest.md, and judging by its name it is a project template for tests rather than a runtime library.

That split is the practical value. A team that wants only the mapping conveniences adds one package and does not take the ASP.NET Core dependency with it. A team that wants Swagger and the tag helpers can take them without the rest of the web package. The cost of fine grained packages is that you end up managing several version numbers, and here that is not hypothetical.

The topics attached to the repository include asp-net, asp-net-core, c-sharp, dotnet, dotnet-core, framework, graphql, graphql-server, nuget, swagger, swashbuckle and taghelpers, which tells you the intended territory: web application plumbing in .NET Core rather than a general purpose utility library.

The version numbers drift apart, and that is the operational catch

Look at the published versions in the list and the pattern is obvious. Boxed.Mapping 7.0.0 Preview 1 was published on 2023-09-14. Boxed.DotnetNewTest 6.0.0 Preview 1 was published the same day, at 2023-09-14. Boxed.AspNetCore 9.0.1 was published the same day too, later in the afternoon.

So the packages do not share a version line. Mapping is on 7, the test template is on 6, the web package is on 9, and the two packages that are not listed with a recent version are Swagger and TagHelpers. Each package is versioned for its own compatibility needs, which is the right way to do it and also the thing that makes a dependency set awkward to keep current.

Two of the three listed versions are explicitly previews, marked Preview 1 in the release titles. A preview package on a public feed is a signal about the API surface, and if you pin it you are accepting that the surface may still change.

The repository itself is not archived and the last push was on 2026-10-14, so the source is moving. But a push is not a release, and for a NuGet package the release is what your build resolves. So the practical situation is that the code is being worked on while the packages you can install are from 2023, and the gap between those two facts is the single most important thing to check before you depend on any of it.

Reading the build: Cake, a pinned SDK and strong naming

The repository layout tells you how the project is put together and, incidentally, how the packages are produced.

There is a Framework.sln at the root and a Source directory, with Tests, Benchmarks and Documentation as siblings. There is a Directory.Build.props, which is the standard way to share MSBuild properties across every project in a repository, and a Key.snk, which is the strong naming key used to sign the assemblies. A strong named assembly gets a stable identity across builds, which matters for a library that many projects reference, and the presence of the key file says the author took that seriously.

The build itself is driven by build.cake, so Cake is the scriptable build tool in use, and there is a dotnet-tools.json, which is the manifest for local tool versions. A global.json pins the .NET SDK version the build expects, which is the mechanism that stops a build from silently moving to a different SDK on a different machine.

There is a renovate.json, so dependency updates are handled by automation rather than by hand, and appveyor.yml plus azure-pipelines.yml sit alongside the GitHub Actions workflow, which is the subject of the next section.

One structural point about the documentation. Each package has its own markdown file under Documentation, and the readme links to each one rather than documenting anything itself. If you are evaluating this project, those five files are the actual documentation, and the readme is an index with badges.

Three CI systems running the same builds on three operating systems

The continuous integration table in the readme is unusual, and worth reading as a statement about how the project validates itself rather than as boilerplate.

Azure Pipelines runs on Ubuntu, on Mac and on Windows, each as a separate job with its own status badge, and there is an Overall row that aggregates them. GitHub Actions runs on Ubuntu, Mac and Windows together under a single Build workflow. AppVeyor also runs on Ubuntu, Mac and Windows. So the same source is being built and tested on all three desktop platforms by three separate CI providers, in parallel, with the results linked from the readme.

Most projects pick one. Running three is a way of saying that a cross platform .NET library is the point and that the build should not depend on one provider being up. It also gives a second opinion, because a package that builds on GitHub Actions but fails on AppVeyor is telling you something about the environment rather than the code.

The trade is maintenance cost, and the evidence for that cost is visible in the release dates. The continuous integration has been kept busy while the packages have not been republished since 2023, so on this project the build being green has not translated into new NuGet versions.

For a consumer, the practical use of the table is narrower than it looks. It tells you the code is exercised on all three platforms, and it tells you the state of each pipeline right now, but it says nothing about whether a version exists that matches your .NET version. That check is against NuGet, not against these badges.

What is missing from the readme, and why it matters

The readme is short, and it is worth being clear that this is a documentation choice rather than a sign of an empty project. The links out are explicit. Each package links to its own documentation file, the Swagger and tag helper packages link to their own files too, and the contributing guide is at .github/CONTRIBUTING.md.

What the readme does not do is tell you what any of the packages do in detail. It does not describe the mapping API, it does not list the tag helpers, it does not say what the Swagger package adds on top of what ASP.NET Core already ships, and it does not show a code sample. There is no installation command, no usage snippet, no configuration example.

For someone choosing a dependency, that is a real cost. A helper package that saves you two days of writing a mapper is a good deal, and a helper package that you have to go and read five separate markdown files to evaluate, each of which you then have to trace to the actual behaviour, is a smaller one. The value of the split packaging only becomes clear once you have read the per package documentation.

The repository also has an Images directory and a separate Dotnet-Boxed/Templates project referenced in the readme for the .NET Boxed project templates. So the framework and the templates are two related but distinct repositories, and the project templates are where a lot of the visible configuration lives.

The homepage for the project is the author's personal site rather than a product page, which fits a project that is one author's collection of helpers rather than a team's maintained platform.

Where this set of packages is the wrong choice

There are cases where reaching for these packages is a mistake, and they are about dependency hygiene and longevity rather than about features.

The first is a new project on a current .NET version. The published versions are from 2023 and cover a .NET Core generation that has since been superseded, and two of the three visible version numbers are preview releases. If you are starting something with a multi year life, taking a package whose last publish is three years old and whose surface may still be settling is a decision you should make deliberately rather than by convenience.

The second is when the platform has already absorbed the functionality. ASP.NET Core has grown its own OpenAPI and Swagger story, and mapping helpers are a crowded space where the framework's own generic support and the wider ecosystem both compete. Adding a third party package for a problem your version of the framework may already solve is a dependency you carry forever for a convenience you could write in an afternoon. Whether that applies depends on your .NET version, and that is exactly what the stale release dates make hard to answer.

The third is the five package overhead for a single need. If you want one helper, taking Boxed.Mapping alone is fine. If your application ends up referencing Mapping, AspNetCore, Swagger and TagHelpers, you are managing four version numbers across two version lines, with two of them on a 7.x and 9.x track respectively, for a set of conveniences.

The fourth is for teams that would rather not depend on one person. The project is the work of a single author with a personal site as its homepage, the contributing guide is the shared community template, and the maintenance story visible from the outside is commits without releases. Nothing here is wrong with that, and the MIT licence means you can fork and maintain it yourself, but it is a fact to weigh.

Against writing the helpers yourself, and against the project templates

Two comparisons put the trade in the right place.

The first is against writing the helpers yourself. A mapping helper, a set of tag helpers and a Swagger configuration are each a day's work for someone who knows the framework well, and the result is code you own with no version to track. The difference in approach is that the packages give you a tested implementation and a documented API for something you would otherwise maintain, and the cost is a dependency and a version number you do not control. For an internal service that will be rewritten in two years, writing your own is defensible. For a product you intend to maintain for a decade and where several teams use the same conventions, a shared package is often the better trade, provided it is still being published.

The second is against the project templates. The readme points you to the separate Dotnet-Boxed/Templates repository for the .NET Boxed project templates, and the Boxed.DotnetNewTest package is the test project template exposed as a NuGet package. The distinction is between a starting point and a library. A template shapes the project you begin with, once, and then it is your code. A helper package shapes the code you write throughout the life of the project. They are complementary rather than competing, and the framework repository is the one that carries the ongoing version burden.

So the deciding question is narrow. If you like the conventions and can live with the version lines, the packages remove real work. If what you need is a starting structure rather than a runtime dependency, the templates are the better place to look.

Editorial conclusion

Adopt the Dotnet-Boxed Framework if you are on .NET Core and want the mapping and tag helper conveniences that the project packages separately, since you can take Boxed.Mapping without pulling in the web stack. Do not adopt it for a new long lived service on a current .NET version, because the last published packages are from 2023 while the repository was pushed to on 2026-10-14, and the versions move independently across packages. Verify first which package version matches the .NET version you target, and read the per package documentation in the Documentation directory before you commit to it.

Frequently asked questions

Official sources

1. Dotnet-Boxed/Framework on GitHub
2. License: MIT
3. Project website
4. README
5. Releases