AspNetWebStack is the source for the ASP.NET generation before Core

The first paragraph tells you which ASP.NET this is not

The README opens with a note that does more work than any other line in the file. It says this repo is for ASP.NET MVC 5.x, Web API 2.x and Web Pages 3.x, and that for ASP.NET Core MVC you should check the AspNetCore repository.

That is a small paragraph with a large consequence. The .NET Framework generation of ASP.NET and the .NET Core generation are different products with different runtimes, different hosting models and different support lives, and their source code lives in separate repositories. A developer arriving at this repository looking for the code behind a modern ASP.NET Core application will find the wrong thing, and the README makes sure they cannot miss the correction.

The framework itself is described as a web framework that gives a powerful, patterns-based way to build dynamic websites and Web APIs, enabling a clean separation of concerns and giving full control over markup.

The audience, then, is the person working on the older stack. In practice that means maintaining an application that already exists: an ASP.NET MVC 5 site, a Web API 2 service, or a Web Pages 3 application, usually on .NET Framework, usually with a specific set of NuGet package versions pinned in packages.config or a project file. The repository is where you read the framework code, and where you would go to understand a behaviour you can only observe from the outside.

There is also a second audience that is easy to miss. This is the kind of repository that people consult to learn how a framework was built, and the tag table, which is unusual and unusually useful, is the entry point for that.

Four products, one repository, one tag

The repository includes four related products:

* ASP.NET MVC 5.x
* ASP.NET Web API 2.x
* ASP.NET Web Pages 3.x
* ASP.NET Razor 3.x

They are developed together and released together, which is why they share a tag. But each is a separate NuGet package with its own version number, and those version numbers do not move in step with each other or with the git tag.

That is why the tags and releases table exists, and it is the single most useful piece of the README. The table has columns for the git tag or branch, other products, the MVC package versions, the Web API package versions and the Web Pages package versions. So a row tells you, for one source tag, exactly which package versions of each of the three products correspond to it.

The rows also record history that a changelog would not. The v2.0.4 row has MVC 4.0.40804, Web API 4.0.30506 and Web Pages 2.0.30506, package version schemes that predate the SemVer style used later. The v2.1 row lists other products explicitly, namely ASP.NET and Web Tools 2012.2 and Visual Studio 2012 Update 2, and notes that it was not on nuget.org, which tells you that a specific release was never distributed through the package feed that most people use.

From v3.0.2 onwards the mapping is much cleaner. The v3.0.2 row shows MVC 5.0.2, Web API 5.0.1 with 2.0.1 in parentheses, and Web Pages 3.0.1. The parenthesised number is the second product in the Web API column, and the v3.3.0 row spells that out with 5.3.0 for the Web API package and Client 6.0.0 alongside it. The parenthesis convention is not explained anywhere in the README, so a reader has to infer it from the rows, and it is worth checking carefully before assuming a package version.

The main branch row is the one to pay attention to when you are not building a specific release. It is marked as New work in the other products column and carries MVC 5.3.1, Web API 5.3.1 with Client 6.0.1, and Web Pages 3.3.1.

Three build systems, a solution filter per target, and a StyleCop settings file

The file listing shows the build infrastructure of a large Microsoft product repository, and it is more revealing than the README.

There are four solution files. Runtime.sln is the main one, Tools.sln covers the tooling, and two solution filters split the runtime by target framework, Runtime.NetFramework.slnf and Runtime.NetStandard.slnf. A filter lets a developer open a subset of a solution, and having one per target framework is how a repository that multi-targets keeps the everyday build small.

Runtime.msbuild is a separate entry point, build.cmd is a Windows batch wrapper, and the build is driven from a shared props and targets pair, Directory.Build.props and Directory.Build.targets, which is the mechanism for applying the same settings to every project in the tree.

Then there is the CI surface, and it is a wide one. azure-pipelines.yml and azure-pipelines-public.yml are the Azure Pipelines definitions, with a .azuredevops/ directory for the rest of that configuration. There is also .travis.yml and .appveyor.yml, which are legacy definitions for other CI systems, and the .github/ directory for the repository side of things. global.json pins the .NET SDK version, and Settings.StyleCop carries the StyleCop analyser settings, which is what enforces the coding style rules across the source.

The src/ directory holds the products, the test/ directory the tests, packages/ the packages, and eng/ plus tools/ the build and tooling infrastructure. A .config/ directory and a .nuget/ directory point at the NuGet configuration, with NuGet.Config at the root.

The practical read for someone who wants to build this is that the repository assumes a Windows development environment with the .NET Framework targeting packs installed, which is what build.cmd and the .cmd convention imply, and that the CI definitions show what the official build matrix was.

A custom licence, a security policy and a code of conduct

The licence field on the repository records a custom licence that GitHub cannot classify, with a pointer to the LICENSE file. The root of the repository holds LICENSE.txt, and that file, not the metadata field, is what governs the terms.

The other governance files are the standard set for a Microsoft owned repository. CONTRIBUTING.md points to the best places to log issues and start discussions, CODE-OF-CONDUCT.md is present at the root, and SECURITY.md documents how to report a vulnerability. The README's contributing section is a single pointer to the contributing page rather than a duplicated procedure, which is the usual pattern for a repository where the contribution process is defined once for the whole organisation.

For an engineering team, the SECURITY.md file is the one that has a direct operational consequence. A framework source repository is a place where a security researcher reports a vulnerability in the framework, and the file records the channel for that. Anyone running an old .NET Framework stack on a public facing system should treat the security policy of the stack as part of their own risk register.

The custom licence designation deserves a sentence of caution rather than alarm. A licence that GitHub cannot classify is not an OSI licence, which usually means terms specific to the copyright holder, so anyone redistributing or shipping this code should read LICENSE.txt rather than assume a permissive standard. This is not legal advice, it is the reason to read the file.

Tagged releases stopped in 2023, the branch kept moving in 2026

The maintenance record is split in two, and reading only one half of it gives the wrong impression.

The recent releases listed are v3.3.0 on 2023-10-24, v3.2.9 on 2022-05-31 and v3.2.8 on 2022-04-12. So the last tagged release of the 3.x line is more than two years old at the time of writing, and before that the gap between 3.2.8 and 3.2.9 was about six weeks, and between 3.2.7 and 3.2.8 a few months. The tag table shows the 3.2.x series stepping through 3.2.6, 3.2.7, 3.2.8 and 3.2.9, each mapping cleanly to the same version of all three products, which is the shape of a well maintained package family in its later years.

The other half is the branch activity. The last push to the repository was on 2026-10-07, and the main branch row in the table carries package versions one higher than the v3.3.0 tag, at MVC 5.3.1, Web API 5.3.1 with Client 6.0.1 and Web Pages 3.3.1, marked as New work. So the source tree is still receiving changes, while the tagged release line has not been cut since 2023.

That is a coherent story for a framework generation that has been superseded. There is no point releasing a new 5.x package to a package feed that most people no longer consume, but there is a point in keeping the source consistent, fixing compilation issues with newer toolchains, and keeping security or correctness fixes flowing into the main branch. It also means an important practical point: if you are running ASP.NET MVC 5.0.2, there is no later 5.x release to move to. The upgrade path out of this stack is not a version bump.

The alternative is ASP.NET Core, and it is a different runtime

The README names the alternative explicitly and links to the AspNetCore repository, and for a reader deciding what to do with an old application that is the most important sentence in the file.

The difference in approach is not a rewrite of the same thing. The generation in this repository targets the .NET Framework, which is the Windows-only framework that shipped with the operating system and was updated in place. ASP.NET Core is a separate, cross-platform framework that was built from the ground up and is developed on a different cadence, with its own package versioning and its own repository.

For a team that has an existing MVC 5 or Web API 2 application, the two realistic routes are to stay on this stack and maintain it, or to migrate the application to ASP.NET Core. The repository supports the first route by giving you the source to read, and by giving you the tag to package version mapping if you have to rebuild a specific version yourself.

There is a third route that is worth naming for anyone who only needs a small piece of the functionality. ASP.NET Core has a different model for some of the concerns this stack handled, and a self contained approach with a static file server and a small service is often enough for a workload that once justified a full MVC application. That is a rewrite of a different size, and the decision belongs to the team that owns the application, not to this repository.

What this repository will not do for you is tell you when to stop using it. It is a source tree, not a migration guide, and the README says nothing about the deprecation of the .NET Framework generation beyond pointing you at the Core repository. Anyone evaluating it should treat the fact that the 3.x release line ended in 2023 as the signal it is, and plan accordingly.

Editorial conclusion

Adopt AspNetWebStack if you maintain an application on the .NET Framework generation of ASP.NET and you need to read, patch or build the framework source itself, because the tag table tells you exactly which tag corresponds to which package versions in your application. Do not adopt it for new work, since the README itself redirects to the AspNetCore repository, and do not expect an active release cadence, because the most recent tagged release is 3.3.0 from 2023-10-24. Before you plan around a specific version, locate the row in the tag table that matches the MVC, Web API and Web Pages package versions in your project, check whether the main branch entry for you is the one you need, and read LICENSE.txt, since the licence field on the repository records a custom licence rather than a standard one.

Frequently asked questions

Official sources

1. aspnet/AspNetWebStack on GitHub
2. Issues
3. README
4. Releases