# ASP.NET Core's Windows Hosting Bundle is the only artifact with the IIS plugin, and it never ships elsewhere

> ASP.NET Core is the cross-platform .NET framework behind web apps, IoT apps, and mobile backends, published under MIT with an active release train across three supported major versions. The detail worth reading is the nightly builds table, where artifact coverage is uneven by platform, where the download links point at a version ahead of any release tag, and where the root package.json is a private build helper whose version field is a placeholder.

**dotnet/aspnetcore** — GitHub describes it as ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.. The repository metadata lists C# as its primary language. The metadata lists the MIT license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/dotnet/aspnetcore
- Website: https://asp.net
- Stars: 38,463 · Forks: 12,441
- Language: C#
- License: MIT
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/dotnet-aspnetcore

## The Hosting Bundle column is N/A on every row that is not Windows

The nightly builds table has three artifact columns, and the third one collapses to a single platform. Windows x64, Windows x86, and Windows arm64 each get a Hosting Bundle installer. Every other row, macOS x64, macOS arm64, Linux x64, Linux arm, Linux arm64, and the three Linux musl rows, is marked N/A in that column. The reason is in what the bundle contains: the ASP.NET Core Shared Framework, the .NET Runtime Shared Framework, and the IIS plugin, known as the ASP.NET Core Module. What this cannot give you is an equivalent single package off Windows, so a deployment that depends on in-process or out-of-process IIS hosting has no counterpart on Linux or macOS and needs its own reverse proxy arrangement. The README's own advice for anyone unsure is to install the SDK, since it has everything except the IIS plugin.

## macOS gets a tarball, Linux arm64 gets rpm but no deb, and musl gets nothing but binaries

The installer coverage across the table is patchy, and the shape of the patchiness tells you what each platform is treated as. macOS x64 and macOS arm64 have no installer at all, only a binaries tarball, and the Hosting Bundle is absent. Linux x64 is the best served, offering both a deb installer and an rpm installer plus a tarball. Linux arm64 has an rpm installer and a tarball but no deb. Linux arm has no installer and only a tarball. The three Linux musl targets, for x64, arm, and arm64, are binaries only. So what a reader cannot do is assume there is a package-manager path matching every CPU architecture. The consequence is that a Debian-based arm64 image and an Alpine image both end up unpacking an archive, and your provisioning has to handle a plain compressed file as a first-class case.

## The nightly download links target 12.0 while the newest release tag is 10.0.12

Look at the version segment in the nightly URLs and it reads 12.0, on rows such as the Windows x64 runtime installer and the macOS arm64 tarball. The recent release tags tell a different story: v8.0.31, v9.0.20, and v10.0.12, all published on 2026-09-08. The repository is not archived and its last push is dated 2026-09-29. So the dogfooding channel sits a full major version ahead of anything tagged. What this cannot be is a preview of the current release; a daily build from that table is closer to the next major than to the version you would deploy. The consequence is that the nightly table is a channel for maintainers and early adopters who want current commits, and picking it over a released framework means accepting a version line that has no published support statement attached to it.

## The root package.json is private, versioned 1.0.0 as a placeholder, and covers only JavaScript inside src/

The root package manifest is not a distributable package. It is marked `private: true` and its version is `1.0.0`, a placeholder that says nothing about the framework version you would install. The twelve workspaces are all nested under `src/`, covering the SignalR TypeScript clients, the MessagePack protocol, the WebAssembly authentication interop for both the default and MSAL variants, JS interop for Components, dotnet-runtime-js, CustomElements, Server.AutoPause, and a project templates test package. Every root script is a fan-out with no logic of its own:

```json
"build": "npm run build --workspaces --if-present",
"lint": "npm run lint --workspaces --if-present",
"test": "npm run test --workspaces --if-present",
"integration-test": "npm run integration-test --workspaces --if-present",
"coverage": "npm run coverage --workspaces --if-present",
"get-version": "npm run get-version --workspaces --if-present"
```

The consequence is that there is no JavaScript entry point to install from this repository. The framework is C#, and the npm side exists to build the browser assets that ship inside it.

## The overrides block is an upward-pinned security floor, not a style choice

The npm overrides list is worth reading as a hardening record rather than as version preference. It forces `tar` to `>=7.5.11`, `serialize-javascript` to `>=7.0.5`, `lodash` to `>=4.18.0`, `cacache` to `>=21.0.0`, `@tufjs/models` to `>=5.0.0`, and `http-cache-semantics` to `^4.1.1`, with a nested override that applies the same `serialize-javascript` floor inside `oidc-client`. Every constraint is a floor rather than an exact pin, so a newer version satisfies it. That pattern lines up with the rest of the repository's security posture: a `.CodeQL.yml` at the root, a `SECURITY.md`, instructions to report privately to the Microsoft Security Response Center through the MSRC Researcher Portal with a response promised within 24 hours, and a link to the Microsoft .NET Bounty Program. The consequence is that the JavaScript supply chain here is defended in the open, and a contributor who bumps a lockfile past one of these floors is not free to do so without a reason.

## Contributing wants Node 20.9 and a directory full of PowerShell and shell scripts

The manifest sets its engine floor explicitly, with Node `>=20.9.0` and npm `>=9.3.1`. Alongside that sit a row of environment scripts at the repository root: `activate.ps1` and `activate.sh` to set up, `restore.cmd` and `restore.sh` to restore, `clean.ps1`, `clean.cmd`, and `clean.sh` to clean, plus `startvs.cmd`, `startvscode.cmd`, and `startvscode.sh` to launch an editor. Build configuration is centralized the same way, with `Directory.Build.props`, `Directory.Build.targets`, `Directory.Build.BeforeCommonTargets.targets`, a `global.json`, and a `NuGet.config`. So what a contributor cannot avoid is two toolchains: .NET for the framework and Node for the assets. The consequence for a Linux-only contributor is that half the entry points are PowerShell, and for anyone who skips the npm side they inherit an incomplete build with no signal telling them which assets are missing.

## The README ships no commands at all, so the entry point is a Microsoft docs site

The get started section is four links and no instructions. It sends you to the Getting Started page on learn.microsoft.com, then to the .NET Homepage at microsoft.com/net for released versions of .NET, then to a Triage Process document for how incoming issues are handled, and finally to a Build from Source document. There is no clone command, no restore command, and no template invocation anywhere in the file. If you want the released framework rather than the source, the .NET Homepage is the place named for it, and the nightly table is the place named for current builds. What this repository cannot do is onboard you, and the consequence is that the first three questions a new contributor has, which interpreter, which SDK, which template, are answered somewhere other than the project. The entry points for the project itself are a weekly Community Standup stream and a roadmap linked from the contribute section.

## Conclusion

ASP.NET Core is a sensible default for a team that already ships on .NET and wants one framework across web, IoT, and mobile backends with a public security reporting path. It is a poor fit for a plan that requires IIS on a non-Windows host, an installer for every target architecture, or a single build story for the C# and JavaScript halves. Before committing, decide which artifact you actually need, since the framework ships as an installer for some platforms and a bare tarball for others, then confirm your Node version against the 20.9.0 floor if you plan to build from source rather than consume a released framework.

## FAQ

### What is ASP.NET Core used for?

It is an open-source cross-platform framework for building cloud-based internet-connected applications, and the named categories are web apps, IoT apps, and mobile backends. It is described as modular components with minimal overhead, running on the .NET runtime, and it is architected for apps deployed to the cloud or run on-premises.

### Is ASP.NET Core the same as .NET Core?

The README does not make that equivalence. It states that ASP.NET Core apps run on .NET, described as a free, cross-platform, and open-source application runtime, and it lists the Runtime as a separate related repository at dotnet/runtime.

### Is ASP.NET Core free?

The repository carries an MIT license in a file named LICENSE.txt, and the README describes ASP.NET Core as open-source and .NET as a free, cross-platform, and open-source application runtime. Other related repositories are listed separately, including Entity Framework Core and Razor.

### Is ASP.NET Core still supported?

The repository is not archived and its last push is dated 2026-09-29. Recent release tags include v8.0.31, v9.0.20, and v10.0.12, all published on 2026-09-08, and a Community Standup is held every week and streamed live.

### how to install asp net core hosting bundle

The nightly builds table lists a Windows Hosting Bundle that contains the ASP.NET Core Shared Framework, the .NET Runtime Shared Framework, and the IIS plugin. Every non-Windows row in that column is marked N/A, and the README advises installing the SDK if you are unsure what you need.

## Sources

- [Official documentation](https://asp.net)
- [Official README](https://github.com/dotnet/aspnetcore#readme)
- [Project repository](https://github.com/dotnet/aspnetcore)
- [Release notes](https://github.com/dotnet/aspnetcore/releases)

---

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