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).
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
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...
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.
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!
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.
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!
Any final solution using runtime section ?