dotnet/Scaffolding: the generators behind ASP.NET scaffolding and msidentity

Two generators in one repository

The README states its purpose in a single line: code generators to speed up development. Then it names what is inside.

The first is ASP.NET scaffolding, described as something that can be used to generate boilerplate code for web apps to improve developer productivity. The details live in a separate README under src/Scaffolding, which the top level links to. That is the usual arrangement for a repository of this kind, where the top level is an index and each feature carries its own documentation.

The second is `dotnet msidentity`, a .NET tool for configuring ASP.NET Core projects to use the Microsoft identity platform, so that the project can authenticate with it. Its documentation is at src/MSIdentityScaffolding/README.md, in the same pattern.

The distinction between the two matters. ASP.NET scaffolding generates application code, the controllers, views, models and DbContext patterns for a web application, so it is about project structure. msidentity is a configuration tool, and its output is configuration that points an existing project at an identity provider, with the app registration, the settings and the middleware wiring that come with it.

The two are in one repository because they share the same generator machinery and the same build and test infrastructure, not because they are meant to be used together.

The repository layout and the .NET SDK conventions

The top level entries tell you this is a .NET SDK style repository, and the naming is the convention that the dotnet organisation uses across its repositories.

There is All.sln as the full solution, and two solution filters, MSIdentityScaffolding.slnf and Scaffolding.slnf, which are the mechanism for building one feature area in isolation. There is a src/ directory for the code, test/ for the tests, and eng/ for the build engine scripts. Directory.Build.props, Directory.Build.targets and Directory.Packages.props carry the shared build settings and the central package version management, so a dependency is pinned in one place rather than in every project file.

There is also a global.json, which pins the .NET SDK version the repository builds against, a NuGet.config, an .editorconfig, an .azuredevops directory for the Azure DevOps configuration, and three pipeline definitions, azure-pipelines.yml, azure-pipelines-pr.yml and azure-pipelines-codeql.yml. The presence of a separate CodeQL pipeline tells you the security analysis runs on pull requests as its own job rather than as part of the main build.

The build entry points are build.sh and build.cmd, plus start-code.cmd and startvs.cmd for launching the development environment, and an es-metadata.yml file for the localization metadata, with a LoginOrLogout.tt file that is a T4 template for the login and logout partials. The scripts/ directory holds the maintenance scripts and the docs/ directory the documentation, including a Getting-Started.md that the README points at for a quick start on building and testing.

How to build and test, and where the documentation points

The README does not contain the build commands itself. It delegates, and it delegates clearly.

For building and testing, it points to docs/Getting-Started.md, and the contributing guide is the reference for the whole workflow, with the README listing what that guide covers: setting up the development environment, understanding the repository structure, making changes to templates and code, testing your changes, and submitting pull requests.

The distinction between making changes to templates and to code is the one to hold on to. A template in this repository is a source file with placeholders that the generator fills in, and the templates are what the generated output looks like. Changing a template changes what every future scaffolded project contains, so a template change and a generator logic change have different blast radii and different testing needs.

The repository also has its own entry point for security reporting, and it is specific about the channel and the timing. Security issues and bugs should be reported privately, by email, to the Microsoft Security Response Center at [email protected], with a response expected within twenty four hours, and a request to follow up by email if no response arrives. The README points to the Security TechCenter for further information including the MSRC PGP key.

That arrangement is standard for a Microsoft repository and it is worth noting for anyone who would otherwise open a public issue describing a vulnerability in a generator.

Where this repository is the wrong place to look

The first limitation is that this is not a product you consume. Nothing here is added to your project, nothing here is installed from it, and the generators themselves ship as part of the.NET SDK tooling rather than as a package from this repository. A developer looking for a package reference will not find one, and the useful output of reading this code is understanding, not a dependency.

The second is that the scope is narrow by design. Two generators, one for ASP.NET web application boilerplate and one for identity platform configuration. There is no general template engine here, no scaffolding for other project types, and no plugin model for adding your own generator, at least as the README describes the repository. Anyone looking for a template system for their own domain is looking in the wrong repository.

The third is the release picture, which needs care when reading the version numbers. The recent releases listed are 7.0.7, 7.0.6 and 7.0.5, all published on 2023-06-19 within a few minutes of each other, and the last push to the repository was on 2026-10-22. So the repository is being worked on while the published versions in this listing are old. For a generator that ships with the.NET SDK, the version in the listing is not what tells you which generator you will actually get, because what you run is the one in your SDK installation.

The fourth is the build environment cost. The eng/ and scripts/ directories and the shared props and targets files mean a contributor is expected to work inside the.NET SDK repository conventions rather than a standalone project, and the getting started document is the entry point for that.

How this compares with the templates in dotnet new and with a code generator of your own

The comparison with the templates in dotnet new is the closest one, and the difference in approach is that dotnet new is the command surface while this repository is where some of the template content and the generators behind it live. When you run a template from the .NET SDK, the output comes from templates that ship with the SDK, and for the ASP.NET and identity cases the machinery is maintained in this repository and flows into the SDK. The practical consequence for a user is that the README is not the place to look for usage, and the man page style help of the tooling is.

The second comparison is with writing a generator of your own, and it is the reason the ASP.NET scaffolding template structure is worth understanding even if you never use it. The template approach, where the generator substitutes into source files rather than emitting code programmatically, is a deliberate design choice with a specific benefit: the template is readable as a template, and the output looks like something a human would have written. The cost is that placeholders have to be well designed, and that a template with a mistake produces wrong output that is hard to notice in a large project.

The third comparison is with a general purpose scaffolding tool such as a project template repository or a code generation framework. Those let you define your own templates and usually come with a plugin model. Here the templates are specific to the framework, they are maintained alongside the framework, and they are tested against the framework's own test suite, which is the arrangement that keeps them in step with the runtime.

The fourth is the identity case. The README points to Microsoft Identity Web as a related project, a library of reusable classes for integrating with the Microsoft identity platform and with Azure AD B2C, and to Entity Framework Core as the source for the data access layer. msidentity generates the configuration that ties an application to that platform, and the platform library itself is a separate dependency.

Licence, contribution and the state of the project

The licence field on the repository records MIT, and the repository has a LICENSE file at the root along with a NOTICE.txt, which is the conventional pairing for a Microsoft open source project.

The contribution path is documented rather than improvised. The README asks contributors to read the contributing guide before opening a pull request, and the guide is explicitly about the development environment, the repository structure, changing templates and code, testing and submitting. A code of conduct is at CODE-OF-CONDUCT.md, and the repository has a.github directory with issue and pull request templates and a CODEOWNERS-style setup in.config.

The build system is the.NET SDK's own, with global.json pinning the SDK, Directory.Packages.props doing central package version management and the eng/ scripts driving the build. The start-code.cmd and startvs.cmd scripts exist so a contributor can bring up the same environment CI uses, which is a small thing that removes a whole class of first-contribution friction.

On the state of the work, the last push was on 2026-10-22, so the repository is being changed, and the release listing shows 7.0.7 as the most recent published version on 2023-06-19. That combination is normal for a repository whose output ships inside the.NET SDK rather than as its own package, and it is a reminder to read the repository for the current state of the generators rather than for a version you can pin.

Editorial conclusion

This repository is worth knowing about if you rely on ASP.NET scaffolding or the dotnet msidentity tool, because it is where those generators are maintained, and it is where a bug in either belongs. It is not a library you add to a project, and it is not something to fork for your own generators, since the tooling is tied to the .NET SDK repository conventions. Before changing a template, read the contributing guide and the Getting Started document in docs/, because the build and test steps are not the ordinary dotnet build. And note that the newest published release in the repository is 7.0.7 from 2023-06-19, so a version number in a template is not a reliable guide to how current the generator is.

Frequently asked questions

Official sources

1. dotnet/Scaffolding on GitHub
2. Issues
3. License: MIT
4. README
5. Releases