.NET Framework vs .NET on Windows Server IIS: Which Runtime to Choose in 2026

Every IIS deployment decision starts with one question that has a real answer, not a preference: does this application need .NET Framework, .NET (formerly Core), or both? This guide gives you the decision in a table, the exact installation steps for each runtime, and the compatibility traps that force an unwanted rewrite six months in.

The Short Answer

Signal in your project	Runtime to choose
Uses System.Web, Web Forms, ASP.NET MVC 5, WCF server-side, ASMX	.NET Framework 4.8 (Windows-only)
ASP.NET Core, minimal APIs, Blazor Server, gRPC services	.NET 8 / .NET 9 (Hosting Bundle)
NuGet packages that only target net48	.NET Framework
Third-party Windows-only COM/ActiveX interop	.NET Framework (or Microsoft.Windows.Compatibility on Core, with testing)
Needs Linux containers, side-by-side versioning, or cross-platform CI	.NET 8/9
Long-lived LOB app, no rewrite budget, stable	.NET Framework 4.8 — still serviced on Windows Server

.NET Framework 4.8.1 ships in-box on Windows Server 2025 and receives security fixes as a Windows component. .NET 8/9 is an out-of-band runtime you install and patch yourself. That single difference drives most of the operational burden — Framework inherits OS patching, Core needs its own update routine.

What “Both Installed Side by Side” Actually Means

They coexist cleanly. .NET Framework lives in C:\Windows\Microsoft.NET\Framework64 and registers under the IIS .NET CLR Version app-pool setting. .NET 8/9 installs under C:\Program Files\dotnet and its IIS integration comes from the ASP.NET Core Module (ANCM) — configured per application, not per app pool. That means:

• A Framework app and a Core app can sit in different IIS applications on the same site.
• Do not set “No Managed Code” app pools incorrectly — Core apps require the pool set to No Managed Code because ANCM handles hosting; leaving it on v4.0 can cause handler conflicts.
• Process identities differ: Framework runs in w3wp.exe as the pool identity; Core spawns its own dotnet.exe child process under that same pool identity.

Install .NET Framework 4.8.1 Workloads

On Server Core or a minimal VPS image, the Framework HTTP features are often not present. Enable them explicitly:

# Serve ASP.NET 4.x apps
Install-WindowsFeature Web-Server, Web-Asp-Net45, Web-Net-Ext45, Web-ISAPI-Ext, Web-ISAPI-Filter

# Add WCF/HTTP activation if the app uses WCF endpoints
Enable-WindowsOptionalFeature -Online -FeatureName WCF-HTTP-Activation45,WCF-Tcp-Activation45 -All

# Confirm which Framework versions are registered with IIS
& "$env:SystemRoot\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe" -lv

Use -i with aspnet_regiis only in old-script muscle memory — on modern Windows Server the role service installation above registers ASP.NET correctly, and re-running the legacy tool has caused more problems than it fixes.

Install .NET 8/9 for IIS

The Hosting Bundle is the only correct install for IIS-hosted Core apps — the runtime alone lacks ANCM and produces HTTP 500.30 at startup.

# Download and install the Hosting Bundle, then verify
dotnet --list-runtimes
dotnet --list-sdks

# IIS must be restarted after ANCM is installed
net stop was /y
net start w3svc

# Confirm the module is loaded
%windir%\system32\inetsrv\appcmd.exe list config -section:system.webServer/globalModules | findstr AspNetCoreModuleV2

If you hit 500.19 or 500.30 after this, the diagnosis path is covered step by step in our Hosting Bundle on IIS guide. Deployment mechanics differ too: Framework apps publish to a folder with msbuild and copy, while Core apps publish with dotnet publish and often deploy via Web Deploy or a zip pipeline — the Web Deploy walkthrough covers the publish profile side.

Performance and Support Reality in 2026

Dimension	.NET Framework 4.8.1	.NET 8 / 9
OS support	Windows only	Windows, Linux, containers
Patching	Via Windows Update	You install and patch the runtime
Throughput (typical API benchmark)	Baseline	3–8× higher requests/sec
Side-by-side versions	4.x only (one per machine)	Multiple majors side by side
Startup / cold start	Faster cold start in w3wp	ReadyToRun/AOT available
Future feature development	Maintenance / security only	Active development

The performance gap is real but rarely a reason to rewrite by itself — a well-tuned Framework app on IIS still serves thousands of requests per second. The honest reasons to move are end of feature development, cross-platform CI, and 3–8× throughput on high-volume APIs. The reasons to stay are `System.Web` dependencies, WCF server endpoints, and a rewrite budget of zero.

Sizing the VPS for Each Runtime

• Framework + IIS, low traffic: 2 vCPU / 4 GB is workable; 2 vCPU / 8 GB is comfortable with SQL Express alongside.
• .NET 8 API on IIS: budget an extra ~200–400 MB per Core app process; 4 GB RAM gets tight with three apps.
• Running both stacks: plan 8 GB minimum — you pay for both process trees.
• High-volume APIs: Core scales better per core, so spend on vCPU rather than on RAM.

Because Core apps multiply processes, and Framework apps multiply app pools, RAM is the resource that runs out first on a small VPS. When you outgrow your plan, move to a host that resizes without re-provisioning: InterServer offers price-locked Windows VPS plans with promo code TRYINTERSERVER for $0.01 in month one, so the resize you do in six months is not a renegotiation. Current Windows plan specifications are compared at windows-vps.org, and if you are still deciding between runtimes for a fresh project, the Windows vs Linux for .NET development comparison settles the hosting question.

Migration Traps, In Order of Frequency

1. System.Web.HttpContext.Current has no direct equivalent. This is the single biggest blocker — untangle it first.
2. Web.config transforms vs appsettings.json — configuration model is different, not ported.
3. Session state. In-memory session is still available but discouraged for scale-out; plan for Redis or SQL-backed session.
4. Windows authentication in IIS. Works for both, but the ANCM forwarding of the Windows identity needs explicit setup and testing.
5. Binary serialization (BinaryFormatter). Removed in .NET 9 — if you persist serialized objects, that is a data migration.
6. Third-party libraries that never published a netstandard2.0 or net8.0 target.

Run the migration in parallel: host the Core version on a second IIS application on the same VPS, cut a percentage of traffic to it, compare error rates and latency, then flip. A Windows VPS with a spare app pool and a few GB of headroom makes that rollout cheap. For anything still greenfield in 2026, start on .NET 8/9 — the Framework choice is now a maintenance decision, not a development one.