Deploying a .NET application to IIS comes down to three deliverables: the publish output, an application pool that matches the runtime, and a site binding with HTTPS in front of it. Get those three right and the app survives reboots, certificate renewals, and bad deploys. Get them wrong and you spend the afternoon chasing 500.30 startup errors. This guide walks through the exact sequence used on Windows Server 2019, 2022, and 2025, with the settings that actually matter and the errors you will most likely hit.<\/p>\n\n
IIS does not compile your project; it runs what you publish. For an ASP.NET Core app, publish a folder, not a source tree. The two relevant modes:<\/p>\n\n
Framework-dependent is the common choice on a dedicated Windows Server. From the project directory:<\/p>\n\n
dotnet publish -c Release -o C:\\deploy\\myapp<\/code><\/pre>\n\nFor a self-contained build targeting Windows x64:<\/p>\n\n
dotnet publish -c Release -r win-x64 --self-contained true -o C:\\deploy\\myapp<\/code><\/pre>\n\nThe output folder contains the application DLLs, the wwwroot static files, and a generated web.config. That web.config is what tells IIS how to launch the app, so treat it as part of the deploy, not an afterthought.<\/p>\n\n
2. Create the application pool<\/h2>\n\n
Open IIS Manager (inetmgr), go to Application Pools, and add a new pool for the app. Three settings matter most:<\/p>\n\n
- .NET CLR Version: select “No Managed Code”. For .NET Core and .NET 5+, the CLR is loaded by the app itself; a managed pool version only adds confusion.<\/li>
- Managed Pipeline Mode: Integrated. This is the default and the mode ASP.NET Core expects.<\/li>
- Identity: ApplicationPoolIdentity (default). It is a virtual account; grant it read permission on the publish folder (give the account named IIS AppPool\\myapp read rights on C:\\deploy\\myapp).<\/li><\/ul>\n\n
For production, adjust the defaults so the app does not idle out:<\/p>\n\nSetting<\/th> Default<\/th> Recommended for production<\/th><\/tr><\/thead> .NET CLR Version<\/td> v4.0<\/td> No Managed Code (for .NET Core \/ .NET 5+)<\/td><\/tr> Managed Pipeline Mode<\/td> Integrated<\/td> Integrated<\/td><\/tr> Start Mode<\/td> OnDemand<\/td> AlwaysRunning<\/td><\/tr> Idle Timeout (minutes)<\/td> 20<\/td> 0 (disabled)<\/td><\/tr> Regular Time Interval (minutes)<\/td> 1740<\/td> 0 (use scheduled recycling instead)<\/td><\/tr> Identity<\/td> ApplicationPoolIdentity<\/td> ApplicationPoolIdentity<\/td><\/tr><\/tbody><\/table><\/figure>\n\n3. Create the site and bindings<\/h2>\n\n
In IIS Manager, right-click Sites and Add Website. Point the physical path at the publish folder, and set a binding with a host name. A host header keeps multiple sites on one IP cleanly separated, and it is required if you ever want to use SNI certificates. Bind port 443 with your certificate rather than leaving the site on port 80; add an HTTP-to-HTTPS redirect with the URL Rewrite module afterwards so nothing leaks over plaintext.<\/p>\n\n
4. web.config essentials<\/h2>\n\n
The publish process generates a web.config containing an aspNetCore element. For a framework-dependent app it looks like this:<\/p>\n\n
\n \n \n \n For a self-contained app, processPath points at the executable (myapp.exe) and arguments is empty. Keep hostingModel inprocess unless you have a specific reason to go out-of-process: in-process avoids the loopback hop and is measurably faster. Turn stdoutLogEnabled on while debugging, then off in production – the log file grows without bound otherwise.<\/p>\n\n
Publishing from a CI pipeline<\/h2>\n\n
dotnet publish behaves identically on a build agent, so the same folder output works from GitHub Actions, Azure DevOps, or a scheduled task on the server. Two common delivery paths: Web Deploy (MSDeploy) pushes the output and can recycle the pool automatically, or a simple file copy plus the app_offline.htm trick from the next section. Either way, the pipeline is the same three steps you just did by hand – publish, place files, recycle – which means the manual run only has to work once, and every deploy after that is scripted.<\/p>\n\n
5. Common deployment errors and fixes<\/h2>\n\n
These five errors account for the vast majority of broken first deploys:<\/p>\n\nError<\/th> Typical cause<\/th> Fix<\/th><\/tr><\/thead> HTTP 500.30 (In-Process Startup Failure)<\/td> App threw during startup – missing config, missing runtime, port conflict<\/td> Read the stdout log and Windows Application event log; fix the first exception listed<\/td><\/tr> HTTP 500.31 (Failed to bind to address)<\/td> Kestrel could not bind the URL\/port<\/td> Remove or fix UseUrls \/ appsettings URLs; let IIS own the binding<\/td><\/tr> HTTP 500.19 (Configuration error)<\/td> Malformed web.config or missing config section<\/td> Validate the XML; check the config error line reported on the page<\/td><\/tr> HTTP 502.5 (Process Failure, out-of-process)<\/td> App process crashed on launch<\/td> Check stdout log; usually a missing runtime or an unhandled startup exception<\/td><\/tr> 404 for static files<\/td> StaticFileMiddleware missing or wwwroot not published<\/td> Ensure app.UseStaticFiles() exists and wwwroot is in the publish output<\/td><\/tr><\/tbody><\/table><\/figure>\n\n6. Zero-downtime swaps<\/h2>\n\n
For routine updates, drop an app_offline.htm file into the site root. IIS detects it, drains in-flight requests, and stops the app; replace the files, delete app_offline.htm, and the app restarts. This gives you clean swaps without touching the pool or the binding. Combined with a scheduled (not time-interval) pool recycle, it keeps deployments predictable.<\/p>\n\n
If you are still deciding where the server should live, compare Windows VPS plans on our table<\/a> to see which providers pre-install recent Windows Server images and give you full admin access for IIS configuration. You can also check our main site<\/a> for Windows Server VPS options across budget and managed tiers.<\/p>\n\nDeploying to IIS is a pipeline, not a single click: publish, pool, bind, HTTPS, verify. Once the sequence is scripted, every future deploy is the same five minutes.<\/p>\n\n
Need a clean Windows Server instance to deploy against? Vultr provisions a Windows Server VPS in about a minute<\/a> with hourly billing, so you can practice this exact publish-and-bind workflow before touching your production host.<\/p>","protected":false},"excerpt":{"rendered":"