Hide menu Last updated: Sep 21 2015

This topic provides an introduction to configuration in Episerver, and describes the configuration files and their structure in the Episerver platform, including the different files and elements used for storing configuration settings and the hierarchy within them.

Configuration files

When you install the Episerver platform, it places files that contain configuration data, connections, and log features in the wwwroot folder in each of the CMS and Commerce Manager websites. 

  • Web.config. The main configuration file for the website application contains configuration for the ASP.NET API and the Episerver CMS API. Commerce also has a web.config file for the backend Commerce Manager site.
  • episerverLog.config. Contains settings for logging with log4net used by both CMS and Commerce.

Note: Previous releases of Episerver CMS used the configSource attibute to extract the episerver and the episerver.framework sections into separate files called episerver.config and episerverFramework.config.

You also may find the following configuration files in an Episerver installation:

  • module.config. A configuration file installed with the CMS sample templates, showing how to deploy new modules to your solution.
  • Web.Debug and Web.Release. Configuration transformation files created by Visual Studio to deploy solutions requiring configuration changes.

You also may have feature-specific configuration files in the solution folder structures for CMS and Commerce.

Configuration hierarchy

Like all ASP.NET web applications, Episerver CMS stores configuration settings in the web.config located in the root directory of the application. ASP.NET uses functionality called configuration inheritance; the file in your project only contains changes and additions to the configuration found in the machine.config file, which is the base configuration for all applications on your machine.

The web.config file is separated into sections containing settings for a specific part of the application, usually based on namespaces. For example, the <system.web> section stores the settings used by the classes in the System.Web namespace. A list of section definitions at the top of web.config tells ASP.NET what sections this application uses in addition to the sections inherited from machine.config. A definition also tells ASP.NET what class to use when you create an object representation of the section. The following example shows a definition.

<section name="episerver.dataStore" type="EPiServer.Data.Configuration.EPiServerDataStoreSection, EPiServer.Data" />

The Episerver CMS API stores settings in several sections. If you scroll down in the web.config file, actual instances of the sections assign values to the section properties.

  <dataStore defaultProvider="EPiServerSQLServerDataStoreProvider">

Accessing configuration settings programmatically

A configuration class can assess any Episerver CMS setting because all settings are typed members of the configuration class, which lets you see settings through IntelliSense. Access to the CMS application settings goes through the static object EPiServer.Configuration.Settings.Instance. You do not to instantiate this class because it is a global static available throughout the application.

Configuration syntax

The configuration files are in XML format and are divided into sections containing configurations for various system parts. This section describes the typographical conventions for the descriptions of configuring elements and attributes. Each subelement is described in two different ways: a pseudo XML structure that shows the hierarchy and includes attributes, and a set of tables that describe each element’s attributes.

Pseudo XML Structure

  • The type of the attribute value appears as the value, such as stringAttribute="string".
  • Elements and attributes appear in alphabetical order.
  • An ellipsis (...) indicates element collections at the same level as the repeatable element.
  • Parentheses indicate (Obsolete elements and attributes).


      <add optionalAttribute="valueType"
       requiredAttribute="valueType" />
   <optionalElement (obsoleteAttribute="valueType")
       requiredAttribute="valueType" />
                <requiredElement (obsoleteAttribute="valueType")
       requiredAttribute="valueType" />

Attribute Tables

Descriptions of attributes appear in table format; one table for each element.

  • Attributes appear with name, default value and description.
  • Attributes appear in alphabetical order.
  • An empty Default Value column indicates that there is no default value.


<requiredElement> Element Attributess

NameDefault ValueDescription
(obsoleteAttribute)   Description of obsoleteAttribute.
optionalAttribute This is the default value Description of optionalAttribute.
requiredAttribute Another default value Required. Description of requiredAttribute.

Configuration elements

Related topics