Dev GuideAPI ReferenceUser Guide
HomeDev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunityDoc feedbackLog In
GitHubNuGetDev CommunityDoc feedback

## Configuration files

When you install the Optimizely platform, it places files that contain configuration data, connections, and log features in the _wwwroot_ folder in each of the Optimizely Content Management System (CMS) and Optimizely Customized Commerce Manager websites. 

  • _web.config_ – The main configuration file for the website application contains configuration for the ASP.NET API and the CMS API. Optimizely Customized Commerce also has a _web.config_ file for the back-end Optimizely Customized Commerce Manager site.

  • _episerverLog.config_ – Contains settings for logging with log4net used by both CMS and Optimizely Customized Commerce.

Note

Previous releases of CMS used the `configSource` attribute 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 CMS 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 Optimizely Customized Commerce.

## Configuration hierarchy

Like all ASP.NET web applications, 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_. The definitions also tells ASP.NET what class to use when the object representation of the section is created.

## Access configuration settings programmatically

Configuration settings can be accessed programmatically through static instances of each configuration section class such as `EPiServer.Configuration.Settings.Instance`. It is, however, recommended that services requiring settings access these through feature-specific options classes. During the initialization of the application, all relevant configuration settings are mapped to the related options value. As such, these classes provide a separation between how the application is configured and how services consume settings. All options classes are registered in the service container and can therefore be injected into any service that requires this information. This also means that options values can be modified during the configuration phase of the application initialization.


You can find more detailed information on individual options classes under the relevant feature section.
## Configuration syntax
The configuration files are in XML format and divided into sections containing configurations for various system parts. This section describes the typographical conventions for the descriptions of configuring elements and attributes. Each sub-element 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).
**Example:**

### 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 Attributes
(Script tags will be stripped)

## Configuration elements
  • [episerver](🔗) 
  • [episerver.datastore](🔗) 
  • [episerver.framework](🔗) 
  • [episerver.packaging](🔗) 
  • [episerver.search](🔗)
  • [episerver.shell](🔗)
  • [module.config](🔗) 
  • [staticFile](🔗) 
  • [episerver.basicAuthentication](🔗) 
  • [.NET SignalR](🔗)
  • [Image Service](🔗) 
  • [Link validation](🔗)