T_D
T_D

Reputation: 3301

prevent duplicate settings keys in web config sitecore

We develop many different web applications that end up in the same public site and use sitecore as cms which merges the different config files to a single web config. Unfortunately there's often duplicate config in the sitecore settings.

Currently: it just joins the config files leaving only the last definition of every duplicate key. Thus updating one of the config files doesn't reflect a change in the merged file, if there's another config file with that setting getting processed later.

Expected: prevent defining 1 config in multiple config files. If there's a duplicate key among multiple config files, it shouldn't silently overwrite but throw an error, so that we can deduplicate our config.

Does anyone know how we could to prevent this? For example a way to override the pipeline that does the merge, to never overwrite anything (or at least when it does it should warn us about it)

EDIT 1:

To illustrate how evil the config-join job is, here are 2 example config files:

aaa.config:

<configuration><sitecore>
   <settings>
      <setting name="key0" value "a-value">
      <setting name="key1" value "a-value">
   </settings>
</sitecore></configuration>

zzz.config:

<configuration><sitecore>
   <settings>
      <setting name="key1" value "z-value">
      <setting name="key2" value "z-value">
   </settings>
</sitecore></configuration>

gets joined to:

<configuration><sitecore>
   <settings>
      <setting name="key0" value "a-value">
      <setting name="key1" value "z-value">
      <setting name="key2" value "z-value">
   </settings>
</sitecore></configuration>

but instead of silently joining the files, I'd love it to throw an exception saying "key1" is ambiguous!

Upvotes: 1

Views: 499

Answers (2)

T_D
T_D

Reputation: 3301

The solution a colleague just suggested: a very strict naming policy, for example prefixing every config key with the project name and country: "Docs_NZ_UploadMaxSize", "Loan_NL_ProductsPath", etc... Which would thus also prevent duplicate keys across projects and/or countries.

Downside: renaming/refactoring in existing projects.

@jammykam's answer sounds more fun though. Anyway, I'll raise both possible solutions after our standup to have a vote which route to take (thus what answer to accept).

Upvotes: 0

jammykam
jammykam

Reputation: 16990

There are no settings available OOTB to prevent this from happening, and it is the expected and intended behaviour in Sitecore. You can read more about how config patching works in this document or this blog post.

It may be possible to provide your own implementation of Sitecore.Configuration.ConfigReader to prevent this BUT Sitecore uses config patches itself even in a default install. Preventing this behaviour is likely to cause Sitecore to break (and/or cause other issues). If you do go down this route then make sure you only target a specific custom folder.

Upvotes: 4

Related Questions