Deploying MVC Applications

Analogy categoryAnalogies

Deployment Options for ASP.NET MVC

A classic ASP.NET MVC application can reach a production server through several paths: Web Deploy (MSDeploy) pushing a package directly to IIS, Azure App Service's built-in publish pipeline, or a manual xcopy-style deployment where compiled output is copied to the server's file system. Each option trades off automation, speed, and control differently, and larger teams often layer a CI/CD pipeline like Azure DevOps or GitHub Actions on top of Web Deploy to automate the push.

🏏

Cricket analogy: A franchise can field its squad via a formal contract signing, a loan transfer, or a direct academy call-up, each a different path to get a player onto the pitch, similar to how an MVC app can reach production via Web Deploy, Azure App Service publishing, or a manual xcopy deployment.

Publishing with Web Deploy

Visual Studio's Publish wizard creates a publish profile (.pubxml) that stores the destination server, site name, and authentication settings for MSDeploy, allowing repeatable, one-click or scripted deployments. On the target server, IIS must have the Web Management Service running and Web Deploy installed so MSDeploy can synchronize files, remove orphaned files, and optionally run pre/post-sync commands like database migrations.

🏏

Cricket analogy: A team's support staff pre-configures a standardized kit bag profile for each away tour so equipment transfers consistently every match, similar to how a Visual Studio publish profile (.pubxml) pre-configures the exact server, credentials, and settings for a repeatable Web Deploy.

bash

# Publish using MSBuild with a Web Deploy publish profile
msbuild MyMvcApp.csproj ^
  /p:DeployOnBuild=true ^
  /p:PublishProfile=Production ^
  /p:Configuration=Release ^
  /p:Password=%DEPLOY_PASSWORD%

# The Production.pubxml (under Properties/PublishProfiles) contains:
# <WebPublishMethod>MSDeploy</WebPublishMethod>
# <MSDeployServiceURL>https://prodserver:8172/msdeploy.axd</MSDeployServiceURL>
# <DeployIisAppPath>Default Web Site/MyMvcApp</DeployIisAppPath>

Configuring web.config for Production

Web.config transformation files, such as web.Release.config, apply XDT (XML Document Transform) rules during a Release build to flip settings like compilation debug from true to false, switch customErrors mode from Off to On, and swap a local development connection string for the production database connection string, all without maintaining two separate full web.config files by hand.

🏏

Cricket analogy: A team switches from a relaxed net-practice ruleset to the strict official match rules the moment the toss happens, similar to how web.Release.config transforms compilation debug="true" into debug="false" the moment a Release build is published.

Deploying with compilation debug="true" left in production not only leaks detailed stack traces to end users, a security risk, but also disables output caching and increases memory usage since ASP.NET keeps extra debugging metadata in memory. Always confirm web.Release.config correctly flips this to false before shipping.

IIS Application Pool and Bindings

Each MVC site should typically run in its own dedicated IIS application pool with an appropriate .NET CLR version and Integrated pipeline mode, so a crash or memory leak in one app doesn't recycle or affect a sibling site sharing the same server. Bindings and host headers map incoming requests for a specific domain to the correct site, and periodic recycling settings (e.g., recycling nightly or after a memory threshold) help recover from slow leaks without manual intervention.

🏏

Cricket analogy: A stadium assigns each hosted tournament its own dedicated ground staff crew so one event's pitch prep never interferes with another's, similar to how a dedicated IIS application pool isolates one site's process from another's so one app's crash doesn't take down a sibling site.

Use a dedicated application pool per site rather than sharing IIS's default app pool across multiple applications. This isolates memory leaks, crashes, and identity permissions, and lets you tune recycling schedules and CLR versions independently per app.

MVC apps can be deployed via Web Deploy/MSDeploy, Azure App Service publishing, or manual xcopy deployment.
Visual Studio publish profiles (.pubxml) store repeatable deployment settings like server URL and IIS site path.
IIS must have the Web Management Service running for MSDeploy to synchronize files remotely.
Web.config transforms (web.Release.config) automatically flip debug, customErrors, and connection strings for production.
Leaving compilation debug="true" in production leaks stack traces and hurts performance.
Each site should run in its own dedicated IIS application pool to isolate crashes and memory leaks.
Bindings/host headers route incoming domains to the correct site, while recycling settings guard against slow leaks.