# Dotnet-Boxed/Templates: .NET Project Templates That Start at Production

> Boxed.Templates ships four dotnet new templates (api, graphql, orleans, nuget) plus .editorconfig and .gitattributes item templates. It solves the first week of a new .NET service, and it assumes you already know what you want the service to look like.

**Dotnet-Boxed/Templates** — .NET project templates with batteries included, providing the minimum amount of code required to get you going faster.

- Repository: https://github.com/Dotnet-Boxed/Templates
- Website: https://RehanSaeed.com
- Stars: 3,484 · Forks: 498
- Language: C#
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/dotnet-boxed-templates

## The problem Boxed.Templates solves, and who it is aimed at

A new ASP.NET Core service is rarely just a controller. It needs a solution file, a project file with the right target framework, logging, configuration, a test project, and a build pipeline that runs on more than one operating system. None of that is hard, but all of it is repetitive, and every team writes it slightly differently. Boxed.Templates exists to remove that repetition. The README describes the project as "Project templates with batteries included, providing the minimum amount of code required to get you going." The emphasis on minimum matters: this is not a sample application you delete afterwards. It is a starting point sized to be extended.

The target user is a .NET developer who has already decided on the framework and the hosting model. The templates cover four shapes: an ASP.NET Core API, an ASP.NET Core GraphQL service, a Microsoft Orleans application, and a NuGet package. Those four cover a large share of what a backend team actually ships. If your work is a Blazor front end or a console utility, the repository does not offer a template for it, and the README does not suggest one is planned. It is also not a code generator you re-run: it produces a project once, and after that the files belong to you.

## How the templates are structured and what dotnet new does with them

The templates are distributed as a NuGet package named Boxed.Templates and consumed through the dotnet new templating engine. That means the mechanism is the standard one: install the package once, and its templates become entries in the dotnet new catalog, addressable by short name. The README lists the short names as api, graphql, nuget and orleans. Visual Studio picks them up too, through a .NET Boxed entry in the project type dropdown, so the same package serves both the CLI and the IDE workflow.

The repository layout confirms the shape of the project. There is a Source/ directory, a Tests/ directory, a Templates.sln solution, and a build.cake script, alongside azure-pipelines.yml and appveyor.yml. The README's continuous integration table shows builds running on Ubuntu, Mac and Windows across Azure Pipelines, GitHub Actions and AppVeyor. That is a deliberate choice: templates that only build on Windows would be a poor fit for teams running containers or Linux CI, and the repository treats cross-platform builds as something worth verifying on every change. Running the same build in three CI systems is redundant in a way that is easy to criticise, but it also means a contributor can reproduce a failure locally with whichever runner they already have.

Two item templates ship alongside the project templates: a .editorconfig file and a .gitattributes file. The README points the .editorconfig at the author's separate EditorConfig repository and describes it as supporting .NET, C#, VB and web technologies. The .gitattributes entry is described as supporting normalized line endings and Git Large File System. These are small, and they are the kind of file most teams copy from an old repository and never revisit. Shipping them as item templates means a new project starts with line-ending normalization already configured, which prevents a class of noisy diffs that otherwise appears only after the first Windows contributor commits.

## Installing Boxed.Templates and scaffolding a first API

The README gives two installation steps. First install the latest .NET Core SDK from dot.net. Then install the template package itself:

```bash
dotnet new --install Boxed.Templates
```

After that command, the templates are available locally. The README recommends inspecting the options before generating anything, because the template exposes feature switches that are not visible from the short name alone:

```bash
dotnet new api --help
```

That help output is where you choose which features to include. The README does not enumerate the options, so treat the help text as the authoritative list rather than anything written elsewhere. Once you have decided, generate the project:

```bash
dotnet new api --name "MyProject"
```

The README shows this exact form, with --name followed by a quoted project name, and notes that you can pass "any other custom options" alongside it. The result is a new directory containing the API project. From there the workflow is ordinary .NET: open the generated solution in your editor, or run dotnet build and dotnet run in the generated folder. The README does not document a rollback command for the template installation, so if you want to remove the package later you will need to check the dotnet new documentation for the uninstall verb rather than this repository. The same three-step pattern applies to the other short names: substitute graphql, orleans or nuget for api and the help output changes with it.

## Where Boxed.Templates is the wrong tool

The templates are opinionated, and that is the point, but it also sets a boundary. If your organisation already has a solution layout, a logging convention, or a build script that other services depend on, generating a Boxed template gives you a second set of conventions to reconcile. The template will not adapt to yours; you adapt the output. That is a real cost when a platform team maintains a golden path, because the generated project will drift from it the moment someone edits the first file.

A second boundary is version currency. The most recent release listed on the repository is Boxed.Templates 7.14.0, published 2022-08-25, with 7.13.4 and 7.13.3 before it in the same year. The repository itself was last pushed on 2026-09-09, so the project is not abandoned, but the release cadence visible in the release list is not the same thing as a template that tracks every .NET release. If your requirement is a template pinned to the newest framework version on the day it ships, verify the generated project's target framework yourself after scaffolding rather than assuming.

A third case: if you are adding one controller to an existing service, none of this applies. Templates are for the start of a project, not for incremental work inside one. There is no mechanism here for re-applying template changes to a project you already generated, and the README does not claim one.

## How this differs from the built-in dotnet new templates

The .NET SDK already ships templates: dotnet new webapi, dotnet new classlib, dotnet new console. Those are the real alternative, and the difference is scope rather than quality. The built-in templates are maintained by the .NET team, updated with each SDK release, and intentionally minimal: a webapi template gives you a project and a couple of endpoints and stops there.

Boxed.Templates makes the opposite bet. It bundles the surrounding decisions, adds item templates for .editorconfig and .gitattributes, and validates the output on three operating systems through three CI providers. The trade is control. With the built-in templates you assemble logging, configuration and test scaffolding yourself, which is more work but leaves every choice open. With Boxed.Templates those choices arrive pre-made, and changing them means editing generated files that the template will not regenerate for you. Neither approach is wrong; they suit different teams. A team with strong internal conventions will find the SDK templates easier to bend, while a team starting from nothing gets further with Boxed.Templates on day one. The practical test is whether you can name the conventions you want before you scaffold. If you can, the SDK templates plus your own script may serve you better. If you cannot, the Boxed defaults are a reasonable place to start arguing from.

## Licence, maintenance and what upgrading costs

The repository is licensed under MIT. In practical terms that is a permissive licence, and the LICENSE.md file at the repository root is the text that governs use. This is not legal advice, and if you are redistributing the templates inside a commercial product, read LICENSE.md and your own legal guidance rather than a summary.

Upgrade cost is the part worth thinking about before you commit. Templates are a one-shot operation: dotnet new api copies files into your repository, and after that the generated code is yours. There is no upstream merge. When Boxed.Templates 7.14.0 or a later version changes a convention, your existing project does not receive it. Upgrading means either scaffolding a fresh project and diffing it against yours, or reading the release notes on the repository's releases page and applying changes by hand. The README points at that releases page and at the projects tab for a to-do list of upcoming features, which is the only forward-looking information the repository offers.

The maintenance picture in short: the last push to the repository was on 2026-09-09, and the newest release listed is from 2022-08-25. Those two facts describe a project that is still receiving commits while its packaged releases are older. Check the releases page before you plan an upgrade, and treat the packaged version rather than the commit history as what you are actually installing.

## Choosing between the four project templates

The four templates are not variations on one theme; they target different architectures. The api template is for a conventional HTTP service, and the README's own preview image links to a dedicated Docs/API.md page. The graphql template is for a GraphQL endpoint, documented in Docs/GraphQL.md. The orleans template is for Microsoft Orleans, the virtual actor framework, documented in Docs/Orleans.md. The nuget template produces a library package rather than a service, documented in Docs/NuGet.md.

That structure is the useful part: each template has its own documentation page in the Docs/ directory, so the decision is made by reading four short documents rather than by guessing from the README. The README itself does not compare them or recommend one, and it does not describe what each template includes beyond the link. If you are unsure which fits, the Docs/ pages are the place to look, not the top-level README. The choice matters more than it first appears, because the Orleans and GraphQL templates pull in hosting models that are awkward to remove once code has been written against them, while the api template is the one you can most easily grow into something else.

## What to check before you scaffold

Two checks are worth doing before you run the generator. First, confirm the SDK version you have installed, since the README makes installing the latest .NET Core SDK step one and the templates were released in 2022. Second, run dotnet new api --help and read the option list, because the README deliberately leaves the feature selection to that help output. The README's usage section reduces the whole CLI to three lines: choose a template name, run --help, then run the template with --name and your options.

That brevity is a fair criticism of the documentation. The README explains how to install and how to invoke, but not what you get. For a template package, what you get is the entire value proposition, and the answer lives in the four Docs/ files and in the help output rather than in the README. Budget ten minutes to read those before generating a project you will keep for years. The generated files are the contract you are accepting, and nothing in the repository will update them for you afterwards.

## Conclusion

Adopt Boxed.Templates if you are starting a new ASP.NET Core API, GraphQL service, Orleans application or NuGet package and you want the surrounding scaffolding decided for you rather than assembled by hand. Skip it if your existing solution already has conventions, or if you need the template to track the newest .NET release on a predictable schedule: the newest release listed on the repository is Boxed.Templates 7.14.0 from 2022-08-25. Before committing, run dotnet new api --help and read the full option list, because the CLI is where the template's real feature surface lives, and the README only shows the --name flag.

## FAQ

### How do I install Dotnet-Boxed/Templates?

Install the latest .NET Core SDK, then run dotnet new --install Boxed.Templates. The README lists those as the two installation steps, and after that the api, graphql, nuget and orleans templates are available to dotnet new and to Visual Studio.

### How do I create a project with Dotnet-Boxed/Templates?

Run dotnet new api --help first to see the available feature options, then run dotnet new api --name "MyProject" with any other custom options you want. The README shows this exact sequence and notes that the template short names are api, graphql, nuget and orleans.

### Can I use Dotnet-Boxed/Templates from Visual Studio instead of the CLI?

Yes. The README documents selecting .NET Boxed from the project type dropdown, choosing the template, and following the instructions, as an alternative to the command line workflow.

### What is the licence for Dotnet-Boxed/Templates?

The repository is MIT licensed, and the LICENSE.md file at the repository root holds the governing text. Review it alongside your own legal guidance if you plan to redistribute anything derived from the templates.

### Does Dotnet-Boxed/Templates include item templates as well as project templates?

Yes. Alongside the api, graphql, orleans and nuget project templates, the README lists a .editorconfig item template and a .gitattributes item template covering normalized line endings and Git Large File System.

## Sources

- [Dotnet-Boxed/Templates on GitHub](https://github.com/Dotnet-Boxed/Templates)
- [License: MIT](https://github.com/Dotnet-Boxed/Templates/blob/main/LICENSE)
- [Project website](https://RehanSaeed.com)
- [README](https://github.com/Dotnet-Boxed/Templates/blob/main/README.md)
- [Releases](https://github.com/Dotnet-Boxed/Templates/releases)

---

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