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).