Best practices: Configure your project for a production environment

Most 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. The symbols loaded for each assembly and the additional processing that needs to be done by the web server don’t provide any benefit after deployment. This is why it is recommended to switch off debugging in the production environment. This is done by setting the value in the <compilation> tag in web.config:

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 https://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. 

When your application encounters an error or an exception that is thrown, it shows a yellow screen of death. That screen is quite revealing and can contain information that you would normally want to hide from abusers. The custom errors configuration element controls what is displayed in that yellow screen. You should set it to “Off” in the production environment to avoid giving more information than needed.

For more information on the custom errors configuration, read https://msdn.microsoft.com/en-us/library/h0hfz6fc.aspx

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:
https://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).