.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. For ASP.NET Core app pools, Microsoft recommends No Managed Code, although the setting is optional rather than a requirement for the application to start.

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. Raff installed Hosting Bundle 10.0.7 on a 4 vCPU / 8 GB Windows Server 2025 VM on April 30, 2026 using the WinGet command below.

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 official .NET support policy lists .NET 10 as an active Long Term Support release through November 14, 2028. Patch versions change during monthly servicing, so install a currently supported .NET 10 patch rather than copying an old patch number from a tutorial.

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 Edge on the server.

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

From our 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 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, Microsoft says to 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 current IIS deployment guidance recommends either 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 our 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.

The intended request path is:

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

IIS owns the public binding in this architecture. 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 because this guide follows the recommended No Managed Code configuration
• http://localhost returns HTTP 200

That verifies the full path:

Browser → IIS → ASP.NET Core Module V2 → ASP.NET Core 10 → 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.

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.
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>

Then create the log folder and grant the app pool write permission:

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

Restart only the affected app pool:

Restart-WebAppPool -Name "YourAppPool"

Inspect the generated stdout log, then 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.

IIS on a Windows VM fits Windows-dependent workloads

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, RDP-based operations, integration with Windows software, or direct control of bindings, certificates, logs, and app pools.

On Raff Technologies, that architecture maps to a Windows VM where the team controls Windows Server and IIS while Raff provides the underlying VM infrastructure.

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 .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: ASP.NET Core 10 Razor Pages app on IIS 10 — Microsoft .NET 10 Hosting Bundle 10.0.7, Microsoft .NET SDK 10.0.203 — on a Raff Windows Server 2025 VM — Production plan, 4 vCPU / 8 GB RAM / 120 GB NVMe, Windows Server 2025 Standard build 26100, us-east datacenter — on April 30, 2026, by Serdar Tekin. We verified end-to-end on a fresh VM: IIS install via Install-WindowsFeature; .NET 10 Hosting Bundle installation via WinGet; ASP.NET Core Module V2 registration; .NET 10 SDK installation; dotnet new webapp --framework net10.0; framework-dependent publish to C:\publish\RaffSampleApp; generated web.config using in-process hosting; replacement of the default IIS site; app pool RaffSampleAppPool with managedRuntimeVersion=""; RX permissions for the app-pool identity; and HTTP 200 through both Invoke-WebRequest and Edge.

The September 10 update revised wording and added links to the other IIS guides. The tested versions and the April 30, 2026 test date are unchanged.

What's next

• Connect to your Raff Windows Server via RDP
• Free SSL on IIS with win-acme
• IIS application pool tuning
• Install SQL Server 2025 on a Windows Server VPS
• SQL Server 2025 Security Hardening on a Windows Server VPS
• RDS CAL licensing guide
• Raff Windows VM plans

What's new, 2026-08-28: Reworked the page around the .NET 10 Hosting Bundle question, added a direct official-download path, clarified what the bundle includes, and preserved the tested IIS deployment workflow. The original Raff test record remains April 30, 2026.

Sources

• Microsoft Learn — Host ASP.NET Core on Windows with IIS
• Microsoft Learn — The .NET Core 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
• Date last verified: 2026-09-10

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