.NET 10 Hosting Bundle for IIS: Host ASP.NET Core on Windows Server

In short

The .NET 10 Hosting Bundle is the Windows installer you need when hosting ASP.NET Core 10 behind IIS. It installs the .NET Runtime, ASP.NET Core Runtime, and ASP.NET Core Module V2 (ANCM) so IIS can start and route requests to your application.

If you already have a Windows Server and only need the bundle, use Microsoft's official .NET 10 download page or install it with WinGet:

winget install --id Microsoft.DotNet.HostingBundle.10 --silent --accept-source-agreements --accept-package-agreements

For a full deployment, install IIS first, install the Hosting Bundle, publish your application, create a dedicated IIS site and app pool, and expose the site through IIS on ports 80 and 443. Microsoft recommends No Managed Code for ASP.NET Core app pools, although the setting is recommended rather than required for the application to start.

Raff Windows VMs provide the Windows Server layer for this IIS architecture. If you are still choosing infrastructure, compare ASP.NET hosting on Raff and the underlying Windows VM plans before deploying.

Browser → Windows Server → IIS → ASP.NET Core Module V2 → ASP.NET Core 10 app

.NET 10 Hosting Bundle download for Windows Server

Download the .NET 10 Hosting Bundle from Microsoft's official .NET 10 download page: open the ASP.NET Core Runtime section and choose Hosting Bundle for Windows. Use the bundle, not only the standalone runtime, because the Hosting Bundle installs the .NET runtime components plus ASP.NET Core Module V2 for IIS.

The original Raff test used Hosting Bundle 10.0.7 on a 4 vCPU / 8 GB Windows Server 2025 VM on April 30, 2026. That test record is preserved. For a new deployment today, install the current supported .NET 10 patch rather than reproducing the old lab patch exactly.

As of September 17, 2026, Microsoft's current .NET 10 release is 10.0.12, released September 8, 2026. Microsoft marks it as a security patch and recommends upgrading older .NET 10 patch levels. .NET 10 remains an active LTS release through November 14, 2028.

winget install --id Microsoft.DotNet.HostingBundle.10 --silent --accept-source-agreements --accept-package-agreements

After installation, verify that both the runtime and IIS integration are present:

dotnet --list-runtimes

Import-Module WebAdministration
Get-WebGlobalModule -Name "AspNetCoreModuleV2" | Format-Table Name, Image

You should see .NET 10 runtime entries and an AspNetCoreModuleV2 result.

What is included in the .NET 10 Hosting Bundle?

The Hosting Bundle is designed for running ASP.NET Core applications with IIS. It includes:

• the .NET Runtime;
• the ASP.NET Core Runtime;
• ASP.NET Core Module V2 for IIS integration.

The SDK is separate. You only need the SDK on the server if you plan to create, build, or publish applications there.

Who this guide is for

This guide is for developers and operators deploying an ASP.NET Core application to Windows Server with IIS. Typical use cases include internal applications, customer portals, APIs, line-of-business systems, and multiple ASP.NET Core sites hosted on one Windows VM.

For larger multi-server deployments, containers or a load-balanced architecture may fit better. The focus here is the common single-server or small-cluster IIS deployment pattern.

What you'll need

• Windows Server 2025 or Windows Server 2022;
• local administrator access through Remote Desktop Protocol (RDP);
• an ASP.NET Core application to deploy;
• the .NET 10 Hosting Bundle;
• optional: a separate build machine or CI runner;
• about 30-45 minutes for a first deployment.

If you need help connecting first, see the RDP connection guide.

.NET 10 is an active LTS release

Microsoft's current .NET support policy lists .NET 10 as an active Long Term Support release through November 14, 2028. As of September 17, 2026, the latest supported patch is 10.0.12. Microsoft releases servicing patches during the support lifecycle and requires supported systems to remain current on released updates.

Three distinctions matter for IIS:

1. The Hosting Bundle and SDK are separate. The Hosting Bundle lets IIS run ASP.NET Core applications. The SDK is needed for dotnet new, dotnet build, and dotnet publish.
2. ASP.NET Core Module V2 is part of the Hosting Bundle. IIS uses it to start and route requests to the application.
3. No Managed Code is recommended, not mandatory. ASP.NET Core boots CoreCLR itself rather than relying on the classic desktop CLR configured for the IIS app pool.

Step 1 — Install the Web Server (IIS) role

Open PowerShell as administrator and run:

Install-WindowsFeature -Name `
    Web-Server, `
    Web-Common-Http, `
    Web-Static-Content, `
    Web-Default-Doc, `
    Web-Dir-Browsing, `
    Web-Http-Errors, `
    Web-App-Dev, `
    Web-Net-Ext45, `
    Web-AppInit, `
    Web-ISAPI-Ext, `
    Web-ISAPI-Filter, `
    Web-Health, `
    Web-Http-Logging, `
    Web-Performance, `
    Web-Stat-Compression, `
    Web-Security, `
    Web-Filtering, `
    Web-Mgmt-Tools, `
    Web-Mgmt-Console `
    -IncludeManagementTools

Verify IIS and its services:

Get-WindowsFeature -Name Web-Server | Format-Table Name, InstallState
Get-Service -Name W3SVC, WAS | Format-Table Name, Status, StartType

Then browse to http://localhost from a browser on the server.

If the IIS welcome page loads, the web server is accepting local requests.

From the Raff test: IIS installed successfully on Windows Server 2025 without requiring a reboot. That is the observed result from the tested VM, not a guarantee for every Windows Server state.

Step 2 — Download and install the .NET 10 Hosting Bundle for IIS

The Hosting Bundle installs the .NET Runtime, ASP.NET Core Runtime, and ASP.NET Core Module V2.

The command used in the original Raff test was:

winget install --id Microsoft.DotNet.HostingBundle.10 --silent --accept-source-agreements --accept-package-agreements

If WinGet is unavailable, download the Windows Hosting Bundle from Microsoft's official .NET 10 download page.

Install IIS before the Hosting Bundle

Install IIS first, then install the Hosting Bundle. If the Hosting Bundle was installed before IIS, repair or run the Hosting Bundle again after IIS is present so ASP.NET Core Module V2 is registered correctly.

Refresh PATH and verify the runtime

$env:Path = [System.Environment]::GetEnvironmentVariable("Path", "Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path", "User")

dotnet --list-runtimes

You should see .NET 10 runtime entries similar to:

Microsoft.AspNetCore.App 10.0.x [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 10.0.x [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Verify ASP.NET Core Module V2:

Import-Module WebAdministration
Get-WebGlobalModule -Name "AspNetCoreModuleV2" | Format-Table Name, Image

If this returns nothing, repair or reinstall the Hosting Bundle as administrator after IIS is installed.

Step 3 — Restart IIS hosting services after the bundle install

The April 30 Raff test used iisreset, and it completed successfully:

iisreset

Microsoft's IIS deployment guidance also supports restarting the server or restarting Windows Process Activation Service and World Wide Web Publishing Service after installing or upgrading the Hosting Bundle:

net stop was /y
net start w3svc

Both approaches interrupt IIS-hosted applications. On a production server with existing sites, schedule the restart during a maintenance window.

Verify the services after the restart:

Get-Service -Name W3SVC, WAS | Format-Table Name, Status

Step 4 — Publish the ASP.NET Core application

Path A — Build on the server for development or staging

The Hosting Bundle does not include the SDK. If the server will create or publish the application, install the .NET 10 SDK:

winget install --id Microsoft.DotNet.SDK.10 --silent --accept-source-agreements --accept-package-agreements

$env:Path = [System.Environment]::GetEnvironmentVariable("Path", "Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path", "User")

dotnet --list-sdks

Create and publish the sample app:

New-Item -ItemType Directory -Path "C:\src\RaffSampleApp" -Force
Set-Location "C:\src\RaffSampleApp"

dotnet new webapp --framework net10.0 --name RaffSampleApp --output .

dotnet publish -c Release -o C:\publish\RaffSampleApp --runtime win-x64 --self-contained false

From the Raff test: the SDK-versus-runtime distinction was the main first-deployment gotcha. The Hosting Bundle can run an ASP.NET Core application but does not provide the SDK commands used to create and publish one.

Path B — Build elsewhere and copy the publish output

For production, build on a workstation or CI/CD runner and deploy the publish output to the Windows Server:

dotnet publish -c Release -o C:\publish\YourApp --runtime win-x64 --self-contained false

Move the publish output, not the source tree, to the server using the deployment mechanism appropriate to your environment.

Framework-dependent publishing is the default here

The command above uses:

--self-contained false

That means the app uses the .NET 10 runtime installed by the Hosting Bundle. A self-contained publish embeds the runtime instead:

dotnet publish -c Release -o C:\publish\YourApp --runtime win-x64 --self-contained true

Use self-contained deployment only when you deliberately want the application to carry its own runtime.

Keep the generated web.config

A normal IIS publish creates a web.config that connects IIS to ASP.NET Core Module V2. A typical in-process configuration looks like:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath=".\RaffSampleApp.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
    </system.webServer>
  </location>
</configuration>

Do not delete or casually rewrite this file. IIS uses it to launch and route requests to the application.

Public traffic should reach IIS, not a separate Kestrel port

Running IIS with ASP.NET Core means IIS owns ports 80 and 443 and forwards requests to the app through ASP.NET Core Module V2; the application itself does not need a separate public Kestrel port.

Public browser request
   ↓
IIS binding on 80/443
   ↓
ASP.NET Core Module V2
   ↓
ASP.NET Core app

Do not expose a random Kestrel application port to the internet simply because the application can listen directly.

Step 5 — Create the IIS site and app pool

Import-Module WebAdministration

Stop-Website -Name "Default Web Site" -ErrorAction SilentlyContinue
Remove-Website -Name "Default Web Site" -ErrorAction SilentlyContinue

New-WebAppPool -Name "RaffSampleAppPool"

# Microsoft recommends No Managed Code for ASP.NET Core app pools.
Set-ItemProperty -Path "IIS:\AppPools\RaffSampleAppPool" -Name "managedRuntimeVersion" -Value ""

New-Website -Name "RaffSampleApp" `
    -PhysicalPath "C:\publish\RaffSampleApp" `
    -ApplicationPool "RaffSampleAppPool" `
    -Port 80

icacls "C:\publish\RaffSampleApp" /grant "IIS AppPool\RaffSampleAppPool:(OI)(CI)RX"

No Managed Code is recommended, not a 500.30 diagnosis

Setting managedRuntimeVersion = "" selects No Managed Code in IIS Manager. Microsoft documents this as optional but recommended for ASP.NET Core because the app boots CoreCLR itself.

A non-empty managedRuntimeVersion is worth correcting, but it is not by itself proof of the cause of HTTP 500.30.

Grant only the permissions the app needs

The command above grants read and execute access to the publish folder. If the application must write logs or uploads, grant Modify only on the specific writable directory:

New-Item -ItemType Directory -Path "C:\publish\RaffSampleApp\logs" -Force
icacls "C:\publish\RaffSampleApp\logs" /grant "IIS AppPool\RaffSampleAppPool:(OI)(CI)M"

Verify the site

Get-Website -Name "RaffSampleApp" | Format-Table Name, State, PhysicalPath, Bindings
Get-IISAppPool -Name "RaffSampleAppPool" | Format-Table Name, State, ManagedRuntimeVersion
Invoke-WebRequest -Uri http://localhost -UseBasicParsing | Select-Object StatusCode, StatusDescription

Expected results:

• the site is Started;
• the app pool is Started;
• ManagedRuntimeVersion is blank;
• http://localhost returns HTTP 200.

Step 6 — Open Windows Firewall for web traffic

New-NetFirewallRule `
    -DisplayName "HTTP (TCP 80)" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 80 `
    -Action Allow `
    -Profile Any

New-NetFirewallRule `
    -DisplayName "HTTPS (TCP 443)" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 443 `
    -Action Allow `
    -Profile Any

For production, configure a hostname, valid TLS certificate, and HTTPS before treating the site as ready for users. If several IIS sites share ports 80 and 443, use explicit hostnames rather than broad wildcard bindings.

For a tested certificate workflow, see Free SSL on IIS with win-acme.

Common IIS and ASP.NET Core errors

HTTP Error 500.30 — ASP.NET Core app failed to start

Treat 500.30 as an application-startup failure. Check these first:

1. Required .NET runtime is missing or out of date.
2. Hosting Bundle or ANCM registration is incomplete.
3. The application throws during startup.
4. The app-pool identity lacks required file permissions.
5. Deployment architecture does not match the server or native dependencies.

Check the runtime:

dotnet --list-runtimes

Check ANCM:

Get-WebGlobalModule -Name "AspNetCoreModuleV2" | Format-Table Name, Image

For the actual startup exception, temporarily enable stdout logging in web.config:

<aspNetCore processPath=".\YourApp.exe"
            stdoutLogEnabled="true"
            stdoutLogFile=".\logs\stdout"
            hostingModel="inprocess">
</aspNetCore>

Create the log folder and grant the app pool write permission, then restart only the affected app pool. Disable stdout logging after diagnosis.

HTTP Error 500.19 — web.config or IIS configuration error

Typical causes include missing ANCM V2, invalid web.config, incomplete publish output, or a missing target runtime.

HTTP Error 502.5 — process failure

This is more common with older out-of-process deployments. Check runtime availability, logs, Event Viewer, permissions, and deployment architecture.

The site works on localhost but not externally

Check the firewall and IIS bindings:

Get-NetFirewallRule -DisplayName "HTTP (TCP 80)", "HTTPS (TCP 443)" | Format-Table DisplayName, Enabled, Direction, Action
Get-WebBinding -Name "RaffSampleApp"

Then verify the public IP, DNS record, and hostname binding.

Port 80 is already in use

Use hostnames when several sites share port 80:

New-Website -Name "App1" -PhysicalPath "C:\publish\App1" -ApplicationPool "App1Pool" -Port 80 -HostHeader "app1.example.com"
New-Website -Name "App2" -PhysicalPath "C:\publish\App2" -ApplicationPool "App2Pool" -Port 80 -HostHeader "app2.example.com"

Create DNS records and HTTPS bindings before production use.

No .NET SDKs were found

The Hosting Bundle is enough to run a framework-dependent ASP.NET Core application. It does not include the SDK required to create, build, or publish one.

Multiple ASP.NET Core sites can share one Windows Server

Use a separate app pool and deployment folder for each site, isolate file permissions, use No Managed Code unless a documented exception applies, and prefer hostname bindings over arbitrary public ports.

If you configure app-pool recycling by memory, remember that the IIS private-memory value is in KB. For example, 2097152 equals 2 GB:

Set-ItemProperty -Path "IIS:\AppPools\RaffSampleAppPool" `
    -Name "recycling.periodicRestart.privateMemory" `
    -Value 2097152

A recycle threshold is not a substitute for diagnosing a memory leak.

For detailed production settings, see IIS application pool tuning.

Persist ASP.NET Core Data Protection keys for production

Authentication cookies, antiforgery tokens, password-reset tokens, and other protected payloads can depend on ASP.NET Core Data Protection keys. Production planning should include a deliberate key-persistence strategy. In multi-server deployments, application instances that must decrypt the same protected data need access to a compatible shared key ring.

When IIS on Windows is the right hosting choice

ASP.NET Core also runs on Linux, containers, and managed application platforms. IIS on Windows Server is practical when the application or operations model benefits from:

• Windows Authentication;
• IIS administration and app-pool isolation;
• RDP-based operations;
• Windows-only software or libraries;
• direct control over bindings, certificates, logs, and server policy.

For a self-managed production deployment, the commercial decision is usually not the Hosting Bundle itself because the bundle is free. The buying decision is the Windows infrastructure underneath it.

A practical Raff starting point is:

*Includes the current compute price plus the $15/month Windows Server Standard SPLA licence. Application databases, extra storage, backups, and other licences are separate.

Use ASP.NET Hosting for the workload-specific overview, Windows VM for the underlying infrastructure, and pricing for the current plan ladder.

Raff supports 3,000+ customers and 15,000+ VMs, with a 99.9% SLA.

Verify the deployment after every release

A simple smoke test should check IIS services, the site, app pool, and an HTTP endpoint:

param([string]$SiteName = "RaffSampleApp", [string]$Url = "http://localhost")

Get-Service -Name W3SVC, WAS | Format-Table Name, Status
Get-Website -Name $SiteName | Format-Table Name, State, PhysicalPath, Bindings
Get-IISAppPool -Name (Get-Website -Name $SiteName).applicationPool | Format-Table Name, State, ManagedRuntimeVersion
Invoke-WebRequest -Uri $Url -UseBasicParsing -TimeoutSec 10 | Select-Object StatusCode, StatusDescription

Use this after each deployment and investigate anything other than running services, a started site/app pool, and the expected HTTP response.

Basic production checklist

Before treating the deployment as production-ready, verify that:

• IIS is installed and running.
• A supported and current .NET 10 Hosting Bundle is installed.
• AspNetCoreModuleV2 is registered with IIS.
• The application has a dedicated IIS site and app pool.
• The app pool uses No Managed Code unless a documented exception applies.
• The app-pool identity has only the required file permissions.
• Public traffic reaches IIS on 80/443 rather than a directly exposed application port.
• DNS, hostname bindings, and HTTPS are configured correctly.
• The application is not running in the Development environment.
• Secrets are not committed to source code or configuration.
• Data Protection keys are persisted appropriately.
• Backups or snapshots are configured and restorable.
• Windows Server and .NET patching are part of the maintenance plan.
• Uptime, disk usage, and application health are monitored.

Tested on Raff

Tested on Raff: ASP.NET Core 10 Razor Pages app on IIS 10, Microsoft .NET 10 Hosting Bundle 10.0.7, Microsoft .NET SDK 10.0.203, Raff Windows Server 2025 VM, 4 vCPU / 8 GB RAM / 120 GB NVMe, Windows Server 2025 Standard build 26100, us-east region, April 30, 2026. Engineer: Serdar Tekin.

The original test verified IIS installation, Hosting Bundle installation through WinGet, ASP.NET Core Module V2 registration, SDK installation, dotnet new webapp --framework net10.0, framework-dependent publish, generated web.config, dedicated site and app pool, No Managed Code, app-pool file permissions, and HTTP 200 through both Invoke-WebRequest and a browser. The screenshots above come from that test. The current supported .NET 10 patch is newer than the test environment, so production servers should be patched to Microsoft's current supported servicing level rather than pinned to 10.0.7.

What's next

• Free SSL on IIS with win-acme
• IIS application pool tuning
• Windows Server Sizing by Workload
• Install SQL Server 2025 on a Windows Server VPS
• ASP.NET Hosting on Raff
• Raff Windows VM

Sources

• Microsoft Learn: Host ASP.NET Core on Windows with IIS
• Microsoft Learn: The .NET Hosting Bundle
• Microsoft Learn: Publish an ASP.NET Core app to IIS
• Microsoft Learn: ASP.NET Core Module for IIS
• Microsoft Learn: Application Pool Identities
• Microsoft Learn: Configure ASP.NET Core Data Protection
• .NET: .NET support policy
• .NET: .NET 10 downloads
• Sources revalidated: 2026-09-17

Microsoft, Windows Server, IIS, .NET, and ASP.NET Core are trademarks of Microsoft Corporation. Raff is an independent infrastructure provider and is not affiliated with, sponsored by, or endorsed by Microsoft Corporation.