Best practices: Configure your project for a production environment

Mostly development tasks in the ASP.NET space require changes in project configuration and Sitefinity CMS is no exception. There is a default web.config file which comes with each new project, and often developers need to edit it (manually or through some other tool) while working on extensions or a custom feature. Sitefinity CMS keeps most of the configuration in separate files in the App_Data folder of the web project, and leaves only the minimum required settings in web.config. Often things needed for development purposes are left in the configuration files on the production environment, which either poses security risks or slows down an application. This article is going to describe what configuration changes you should have in mind when deploying your sitefinity websites.

Debugging needs to be explicitly enable in the web.config file while doing development on a web project. While this provides a lot of help during development, it creates some overhead that is useless in a production environment. We recommend to switch off debugging in your production environment. For more information, see Administration: Debug mode.

Managing the differences between debug and release configuration files manually is tedious. You should remember what to include or exclude on each deployment. For similar scenarios, Microsoft implemented configuration transformations. In essence, this means that you keep two versions of each config file – one for debugging environments, and one for release. Depending on the build configuration that you use for your project, ASP.NET automatically uses the corresponding config file. More on config transformation can be read at http://msdn.microsoft.com/en-us/library/dd465318.aspx

The compilation of Sitefinity CMS pages (as opposed to normal ASP.NET pages) is managed by the CMS rather than ASP.NET. This is why Sitefinity CMS implements caching options for those pages. Unless there are circumstances that prevent you from doing so, you should always enable output caching for projects that you deploy. Cases where caching may be a problem are usually dynamic content that is generated by some widget (The LoginName widget is an example).

There are multiple cache profiles that you can configure in Sitefinity CMS. By default, everything uses the Standard profile. Each caching profile controls the duration for which items are kept in the cache, whether there is a sliding expiration, and the maximum size of cached items. You can also create your custom profiles. For more read the documentation about Administration: Cache settings.

When creating or editing a page in Sitefinity CMS, you can control which cache profile it uses. For pages that generate high traffic, we recommend using profiles with longer durations for the cache. This is not the default, so you should modify each page’s settings separately, depending on your traffic volume. 

In case your Sitefinity CMS website encounters a problem, your database server goes down, or your custom code throws an error, the user browsing the site will be presented with an error screen. This error screen is also known as YSOD, or the “yellow screen of death”. The error screen can contain sensitive information and make it visible to the public, for example your connection string, important variable names, and so on. You must configure error pages to make sure such information is not visible on the live site. For more information on the custom errors configuration, read Administration: Custom error pages.

The Sitefinity CMS UI consumes WCF services to perform read/write operations on data. Often, when working with those services developers enable tracing to be able to track down errors or incorrect usage.

Tracing, like debugging, also introduces overhead which you don’t need in a production environment. In cases when you don’t want to monitor the production application at all, you can disable tracing altogether. You can also leave it enabled, but limit the sources you trace. More information on recommended tracing settings for a production environment can be found in MSDN:
http://msdn.microsoft.com/en-us/library/aa702726.aspx

As a web server IIS can serve static and dynamic content. Dynamic content goes through the ASP.NET pipeline and executes the code in your pages (including Sitefinity). Static content are just files returned to the browser as they are (CSS, images, etc.). The browser usually caches the static content, so it saves further trips to the server for the same resource. You can control the expiration period of this cache through response headers. By default, static content expires after 31 days. This is configured by a setting in your web.config file.

You can change this value while doing development. However, when deploying to production, we recommend you leave it to 31 days. Longer is better, in case your static resources don’t change that much (you are not doing active development and changing CSS rules).