We Keep Coding

Upgrade settings from old version with different name

We use app.config to store user settings, but changed the name of the exe... for reasons. I need to be able to upgrade the settings from version 1.4 called name1.exe to version 1.5 now called name2.exe.
I've tried several methods, the first was to add code in Program.cs Main() where it would use System.Configuration.ConfigurationManager.OpenExeConfiguration(System.Configuration.ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath to find the path where the new settings file should go, and search the base path of that setting to find the 1.4 version under the old name, then copy the 1.4 folder into the correct part of the path where the Properties.Settings.Default.Upgrade() would work like normal.
I've also tried replacing the new app.config file with the old one and calling Properties.Settings.Default.Reload(); and doing the same but just restarting the application.
Each of those methods worked, even in release mode outside the ide. But we also use SmartAssembly to merge some other dlls into our exe's assembly. Smart assembly must do some unknown magic, because it doesn't work after being SmartAssembled.
If I manually copy the old settings to the new location (replacing the app.config) then try to run my app doens't even start, it must crash right away. Again, only after using SmartAssembly to merge our dlls. I've narrowed the crashing down to this part in the xml...
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<sectionGroup name="userSettings">
<section name="DllNameA.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
<section name="DllNameB.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
<section name="ExeName.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
That last part of the xml "section name=ExeName.Properties.Settings..."
was not there in the old settings file. I'm not sure why it's added now, but it works if I manually add it to the old settings file when copying it over.
Is there a way to make this work?

This probably isn't the right way to do this, but I did just edit the xml to add the missing section and it is working.

Relative path for Config section file in Web.config

I have several console applications and one MVC Web API application inside a folder. Is it possible for all these applications to refer to a constants.config file that resides in the parent folder?
In each of the Web.config files of all the applications, i have declared the config section as following:
<configSections>
<section name="Constants" type="System.Configuration.NameValueFileSectionHandler, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</configSections>
<Constants file="~/Constants.config">
But the Constants.config is not read by the applications. How to give the path correctly?

<userSettings> in app.config Could not find schema information for the element 'userSettings'

Hello when I try to add parameters to the settings table
I get multiple messages for each parameter I add.
e.g.:
Could not find schema information for
the element 'userSettings'
Could not find schema information for
the element 'setting'
Could not find schema information for
the attribute 'serializeAs'
In the app.config I get:
<project1.Properties.Settings>
<setting name="ccc" serializeAs="String">
<value>vvv</value>
</setting>
</project1.Properties.Settings>
I can use, edit and save this parameter, but the messages really annoy me.
I use the following schema (and selecting other like 20 and 30 did not help):
C:\Program Files (x86)\Microsoft Visual Studio 9.0\xml\Schemas\DotNetConfig.xsd
Any ideas?
edit:
following Hans post here is my configSections
<configSections>
<sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="project1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
I don't know what it is for and if I should change it - yet here it is :)
Thanks Asaf

Well, that doesn't look healthy. Note how it is not valid XML, the project... element is mismatched with RuthSiteManager...
Not sure how it got that way, you'll have to edit it into shape. I guess you want to rename "project1". Avoid editing the .config file by hand otherwise. And make sure you have the required <configSections> element as well.

I just had this same issue. The fix I came across was to do a 'Clean Solution' followed by a 'Rebuild Solution'. This seems to rebuild the files correctly.

Split user.config into different files for faster saving (at runtime)

In my c# Windows Forms application (.net 3.5 / VS 2008) I have 3 settings files resulting in one user.config file.
One setting file consists of larger data, but is rarely changed. The frequently changed data are very few. However, since the saving of the settings is always writing the whole (XML) file it is always "slow".
SettingsSmall.Default.Save(); // slow, even if SettingsSmall consists of little data
Could I configure the settings somehow to result in two files, resulting in:
SettingsSmall.Default.Save(); // should be fast
SettingsBig.Default.Save(); // could be slow, is seldom saved
I have seen that I can use the SecionInformation class for further customizing, however what would be the easiest approach for me? Is this possible by just changing the app.config (config.sections)?
--- added information about App.config
The reason why I get one file might be the configSections in the App.config. This is how it looks:
<configSections>
<sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="XY.A.Properties.Settings2Class" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
<section name="XY.A.Properties.Settings3Class" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
I got the sections when I've added the 2nd and 3rd settings file. I have not paid any attention to this, so it was somehow the default of VS 2008. The single user.config has these 3 sections, it is absolutely transparent.
Only I do not know how to tell the App.config to create three independent files instead of one. I have "played around" with the app.config above, but e.g. when I remove the config sections my applications terminates with an exception.

As you have already discovered, VS puts all config and settings files in your project into one big applicationname.exe.config file when compiled and as far as I know you can not load another config file as the "main one".
One solution is to have your own implementation of a settings class and have it load another file.
An alternative to this could be to use the OpenMappedExeConfiguration method in ConfigurationManager.. You can load a config file and access its appsetting values using
ExeConfigurationFileMap map = new ExeConfigurationFileMap();
map.ExeConfigFilename = "test.config";
Configuration configuration = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
var section = ((AppSettingsSection)configuration.GetSection("appSettings")).Settings;
foreach (string key in section.AllKeys) {
Console.WriteLine("{0}={1}", key, section[key].Value);
}
You should be able to get a custom section and use the Save method on it as well.

If it is slow , instead of doing in single file you can do it in multiple user.config.
Note: But when i worked on user.settings i found one difficulty, Once the application is uninstalled the settings wont remove form the saved location as well as only administrative permission user can access those files. So please make sure that your setting files in needed or not

Eventually I have used my own settings provider in order to achieve my goal:
I found two resource most useful getting started writing such a provider
www.codeproject.com/KB/vb/CustomSettingsProvider.aspx?msg=2934144#xx2934144xx
www.blayd.co.uk/download.aspx?pageid=1013
I have used a modified version of 1. using some of the know-how in 2. I can set for each setting which provider to use, so I stick with that approach. However, i have tried to avoid writing my own provider for a long time, but whenever I checked on this topic, i have found not better approach at all to split the sections into independent files.
However, I also find Patrick's approach interesting and will give it a trial as soon I have the time. Thank you!

How do I reference configuration information from within multiple class libraries?

I've got a bunch of DLL projects that I'm pulling into my application, each contains their own Settings.settings/app.config. When I compile the app and run for debugging, everything works just fine, but come deployment time I can't get my DLLs to read their own settings files.
I've been doing some reading and it has become apparent that there's a couple of methods to getting each dll to read its own configuration - one is to dedicate a .dll.config to the library and the other is to embed the dll's configuration in the process.exe.config.
I'm having significant issues trying to implement either and I wondered if anyone has any good docs on this - there appears to be a shortage on the Net.
I'd like a separate .dll.config for each of the libraries if possible, but in a pinch, getting each of my libraries to read their own section of the process.exe.config will do.
Can anyone point me in the right direction because I'm so close to rolling this application out but this stumbling block is causing me a significant headache.
Edit: When I merge the configuration files, I start getting TypeInitializer exceptions when I initialize objects withing my libraries. This is likely just me being retarded, but does someone have a working example of a merged config file and some basic demonstrative code for reading it from multiple assemblies?

What are the "significant issues" you encountered? I started with embedding the dll's config in the exe's config, which worked, but was cumbersome. I now have all the config stuff in one dll project. The only thing I needed to do to make that work (besides copying the settings over) was to change the Settings class to be public.
Here's an example of a merged app.config that works:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="SharedConfig.Client.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
<!-- Begin copy from library app.config -->
<section name="SharedConfig.Library.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
<!-- End copy from library app.config -->
</sectionGroup>
</configSections>
<applicationSettings>
<SharedConfig.Client.Properties.Settings>
<setting name="Bar" serializeAs="String">
<value>BarFromClient</value>
</setting>
</SharedConfig.Client.Properties.Settings>
<!-- Begin copy from library app.config -->
<SharedConfig.Library.Properties.Settings>
<setting name="Bar" serializeAs="String">
<value>BarFromLibrary</value>
</setting>
</SharedConfig.Library.Properties.Settings>
<!-- End copy from library app.config -->
</applicationSettings>
</configuration>

Have each class library define configuration settings in a custom ConfigurationSection.
Then add custom section handlers to your process.exe.config file.
This MSDN article is pretty comprehensive in its explanation, with examples in both VB and C#.

See If app.config for a DLL should be in the "main config"… what do we do with WCF References in DLLs?. The real answer is "copy and paste". That's unfortunately the general solution Microsoft had in mind. In some cases, the .NET 2.0 Settings mechanism can be used, as it bakes the default values into the DLL itself. At runtime, the DLL can then save updated settings - into the .exe.config.