Magnus Rahl
Jun 10, 2011
  13072
(2 votes)

Today’s gotcha: configSource on the runtime section element

It’s friday and time for another today’s gotcha! Or one that took the better part of my week actually…

Exports and transforms are great

We have an environment with many different configurations for our web applications, so CM is quite a big issue, especially since we are using CI. To manage it we have exported all sections of web.config using the configSource attribute, as you might know from <connectionStrings configSource=”connectionStrings.config” />.

You can do the same for all sections like episerver, episerver.framework, compilation… Whole sectionGroups can’t be exported however, you have to export the contained sections one by one, like the services, client and behaviors sections under the system.serviceModel section group.

We then do transforms for many of these section files as well (yes you can do it for other files than web.config but it is a bit tricky) to maximize the reuse of configuration and only specify the differences between environments.

Trouble in paradise

I was adding EPiServer Mail to our solution and suddenly it stopped working, showing various errors. There were many changes so it took me a while to find the real problem, which was found using the Assembly Binding Log Viewer (fuslogvw), thanks to Anders Hattestad for pointing me in the right direction. A quick tip there is that if you are trying to log binds from the IIS, the app pool, it seems, has to run as your own user account or nothing will show up in the log).

It turned out that some EPiServer assemblies were being loaded with the wrong version. The culprit was the EPiServer.Common.Web.Authorization.Multiplexing.dll which was referencing the old 5.2.375.7 (5R2) version of EPiServer.dll (this is a 6R1 project).

But hey, there’s an assembly redirect for that! Or so I thought… It turns out that the runtime section happily accepts the configSource attribute but it does not read the external file! It seems we were only lucky that the correct versions of assemblies were bound anyway.

I verified this first by copy-pasting the section back into web.config to see that it loaded the correct version then. Then I took one of our other applications in a different environment (yet unaffected by EPiServer Mail) and garbled up the external runtime file (removed a closing dependentAssembly tag). The site still started without problems. But when i pasted the whole section into web.config it crashed immediately in startup pointing to the missing closing tag. So the conclusion is that (at least) the runtime section can’t be read from an external file, it will be ignored.

UPDATE: It seems the application didn’t restart when I had removed the required tag, so the 500 error only came a bit later… So that test was no good. However, instead I changed the assembly redirect for one assembly to point to a non-existing version. This caused a 500 error when the runtime section was in web.config but caused no error when using an external file (this time I made sure to re-save web.config too to restart the app after changing the external file). So the conclusion is still that the runtime section in an external file will be ignored (even if the file itself is actaully read).

Jun 10, 2011

Comments

Jun 10, 2011 09:22 AM

Good catch! I've been down that road (splitting configuration into separate files).

Have you looked at http://ctt.codeplex.com/ ? It lets you do the regular XDT (Visual Studio style), but on any xml file, from the command line. I try to keep the number of config files low, and valid for development, and then I transform for the different environments on the build server.

CTT also have parameter support, for values that repeat in the same file, and to keep the number of different transformation files down (one transformation file, n different environments - if the transformation is syntactically the same across environments.)

/Steve

Magnus Rahl
Magnus Rahl Jun 10, 2011 10:00 AM

We're using an approach very similar to what's described here: http://vishaljoshi.blogspot.com/2010/05/applying-xdt-magic-to-appconfig.html

Because we exported all sections (thought it would be good while we were at it...) and then added many environment transforms for most of them (just temporarily rename to web.config which will give you the VS context menu alternative to add transforms, then rename back) we have hundreds of configs and transforms. So CTT would absolutely have been a better alternative for us, but we'll stick with what we have for the moment. It's still a million times better than the old pre-CI "system" based on writing instructions on what to update in each environment...

Jun 10, 2011 04:55 PM

Sneaky stuff! Also surprising as configSource is supposed to work for config _sections_ in general.

However, after taking a peek inside machine.config it's not as surprising anymore:



"IgnoreSection" being registered to handle "runtime" seems to suggest that this configuration is read by other means altogether, and apparently this other handling is not take configSource-aware.

Magnus Rahl
Magnus Rahl Jun 10, 2011 05:00 PM

Very satisfying to find out the cause, thanks Håkan! We were about to check how all other sections behave by brute force (adding strange configuration to them to see if it was ignored or not) but now we know where to look!

Magnus Rahl
Magnus Rahl Jun 10, 2011 05:06 PM

Here's how you're apparently supposed to handle external files in the case of the runtime section, say hello to the linkedConfiguration element. I won't bother, the assembly redirects stay in web.config for now.

tompipe
tompipe Aug 1, 2011 10:13 AM

I tried this just the other day, and after some research, found that according to the documentation (http://msdn.microsoft.com/en-us/library/ms404289.aspx) - the assemblyBinding section defines a child element named . This is used for "simplifying the management of component assemblies by allowing application configuration files to include assembly configuration files in well-known locations, rather than duplicating assembly configuration settings."

And gives an example of:







This implies you can indeed redirect the section to an external file, and possibly even share redirect bindings between projects (should you ever need to!) albeit not using the typical configSource attribute.

I've not tried it myself yet, but it looks like it might work!

Jun 30, 2015 02:13 PM

Any final solution using runtime section ? 

Please login to comment.
Latest blogs
Plug-in manager is back in CMS 12

Plug-in manager is back in the UI, what is it and how can i use it?

Luc Gosso (MVP) | Oct 6, 2022 | Syndicated blog

Display Child Pages in Content Delivery API Response

The below example will implement an instance of IContentConverterProvider to customise the serialisation of PageData and output child pages in the...

Minesh Shah (Netcel) | Oct 4, 2022

Bring the Report Center back in Optimizely CMS 12

The Report Center has been a part of Optimizely CMS since its first debut in version 5R2 in 2008, but in CMS 12, it's removed! Don't despair! Make...

Tomas Hensrud Gulla | Oct 4, 2022 | Syndicated blog

Customizing Property Lists in Optimizely CMS

Generic property lists is a cool editorial feature that has gained a lot of popularity - in spite of still being unsupported (officially). But if y...

Allan Thraen | Oct 2, 2022 | Syndicated blog