Deploying Web Pages Sites

WebMatrix offers a built-in Publish command that uploads a site's files directly over FTP or FTPS to a hosting account, which is the fastest path for a small site but re-uploads the entire file set each time unless the host supports incremental sync. Web Deploy, invoked from WebMatrix or Visual Studio using a downloaded publish profile, instead synchronizes only changed files, can run pre- and post-deployment SQL scripts to update a remote database schema, and is the mechanism Azure App Service publish profiles use under the hood when a developer clicks Publish against an Azure Web App target.

Before going live, web.config must be adjusted for production: customErrors mode="On" (or RemoteOnly) hides detailed stack traces from anonymous visitors while still logging the full exception server-side, and the compilation element's debug attribute must be set to "false" so pages compile with optimizations and never leak source-level debugging information to a client. Connection strings in the deployed web.config typically point at the production database server rather than a developer's local SQL Server Express instance, and Web.config transformations, such as Web.Release.config, automate swapping these values so a developer never has to remember to hand-edit settings before every publish.

Sites using SQL Server Compact or a local SQL Server Express .mdf file store that database physically inside the App_Data folder, which must be included in the deployment package and, on IIS, given write permission for the application pool identity, commonly IIS_IUSRS or a specific app pool account, or every insert will fail with an access-denied error even though the site otherwise loads fine. Because App_Data is configured by default to reject direct HTTP requests, placing the database file there also protects it from being downloaded directly by a visitor who guesses its URL, unlike a database file mistakenly placed in a publicly served folder.

On IIS, the application pool's .NET CLR version must match what the site was built against, and Integrated Pipeline mode should be used unless a legacy component specifically requires Classic mode, since Integrated mode lets ASP.NET modules like forms authentication participate fully in the request pipeline alongside native IIS modules. The application pool identity, often ApplicationPoolIdentity by default, needs read access to the site's files and, as noted above, write access to App_Data if a local database or uploaded files folder is used, and mismatched or overly broad permissions are a common source of either mysterious 500 errors or unnecessarily wide-open security exposure.