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.
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.
Note: Previous releases of Episerver 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 Episerver installation:
You also may have feature-specific configuration files in the solution folder structures for CMS and Commerce.
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. The definitions also tells ASP.NET what class to use when the object representation of the section is created.
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.
public void ConfigureContainer(ServiceConfigurationContext context)
context.Services.Configure<DataAccessOptions>(o => o.UpdateDatabaseSchema = true);
You can find more detailed information on individual options classes under the relevant feature section.
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 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.
<someElement> <optionalCollectionElement> <add optionalAttribute="valueType" requiredAttribute="valueType" /> ... </optionalCollectionElement> <optionalElement (obsoleteAttribute="valueType") optionalAttribute="valueType" requiredAttribute="valueType" /> <requiredElement (obsoleteAttribute="valueType") optionalAttribute="valueType" requiredAttribute="valueType" /> </someElement>
Descriptions of attributes appear in table format; one table for each element.
|(obsoleteAttribute)||Description of obsoleteAttribute.|
|optionalAttribute||This is the default value||Description of optionalAttribute.|
|requiredAttribute||Another default value||Required. Description of requiredAttribute.|
Last updated: Dec 18, 2017