AppDomains and user.config

Previously I had a problem with an application using different AppDomains. In one AppDomain I wrote some settings to an user.config file. And then I got in another AppDomain the following exception:
System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize
---> System.Configuration.ConfigurationErrorsException: Unrecognized configuration section userSettings. (C:\Users\uuuuuuuu\AppData\Local\cccccc\aaaaaaaaaaaaaa_Url_4v0elz3yo0gytsdhg5vusobffefqs0so\1.0.0.0\user.config line 3)

This was very strange since in this AppDomain I even didn’t use any user.config. After some hours of investigation, I found the problem. The user.config file will be written to

<Profile Directory>\<Company Name>\<App Domain>_<Evidence Type>_<Evidence Hash>\<Version>\user.config

• <Profile Directory>: %APPDATA% or %LOCALAPPDATA%
• <Company Name>: value of AssemblyCompanyAttribute, trimmed to 25 characters, invalid characters replaced by '_'
• <App Domain>: friendly name of the current AppDomain, trimmed to 25 characters, invalid characters replaced by '_'
• <Evidence Type> and <Evidence Hash>: some magic from AppDomain’s evidence
• <Version>: value of AssemblyVersionAttribute

In my case, all these properties had the same value. Therefore the whole stuff got mixed up: 

• company name: ok this is by purpose the same
• version: I generated the version from the build number for all assemblies, but also this is not so uncommon
• evidence: I created the new AppDomains with
  AppDomain.CreateDomain(appDomainName, null, appDomainSetup);
  The second parameter is the evidence for the new AppDomain. If it is null, the evidence from the current AppDomain will be taken. Also understandable.
• App domain: this was the sticky point. I used for the AppDomain’s name the full name of the main assembly. Since I used a pattern like Company.Application.Subsystem..., this name was simply too long. The first 25 characters were all the same...

So the solution was quite easy: I just had to change the AppDomain’s name. But the trail to the solution took its time. Maybe this blog can accelerate your search a little bit.

BTW: Finally I checked the source code of System.Configuration.ClientConfigPaths.cs. This helped me a lot to understand the problem.