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!
Related
I added a app config file to C# project and wanted to store config for log4Net and some basic app setting. The generated app.config file is empty.
I looked at other projects. They had an applicationSettings section. So I added a applicationSettings section; by copy pasting from some other project. Then I did not understand what some of the attributes were; like the PublicKeyToken b77a5c561934e089. I tried searching to see if the section is automatically generated; could not find how. The online resources point to complicated schemes about writing your own config class. My needs are far simple. Online resources do not document the attributes per se.
So short of copy pasting from some other project, how do you get around to adding this section?
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="CrawlReponseHandler.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false"/>
</sectionGroup>
The section is added automatically by going to project -> properties -> settings tab and adding the properties.
I'm posting my question here and to CodeProject, as a question to the famous article series on the mysteries of config files.
From the article:
Optionally, you may specify culture, version and public key (for
signed assemblies) values if you wish to ensure only a specific
version of an assembly is searched for when your .config file is
parsed.
I'm using the following code to open and initialize the config file:
ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = path;
config = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);
section = (OptionsSection)config.GetSection("myoptionsdata");
if (section == null)
{
section = new OptionsSection(0, "aaaa", "bbbb", "cccc",14);
config.Sections.Add("myoptionsdata", section);
config.Save(ConfigurationSaveMode.Full);
}
That creates the following:
<configSections>
<section name="myoptionsdata" type="my.namespace.OptionsSection, myAssembly,
Version=1.0.3.0, Culture=neutral, PublicKeyToken=111222aaaabbb"
allowLocation="true" allowDefinition="Everywhere"
allowExeDefinition="MachineToApplication" overrideModeDefault="Allow"
restartOnExternalChanges="true" requirePermission="true" />
</configSections>
Notice how the 'type' has Version, Culture, and the PublicKeyToken. I need to eliminate these, or at least the Version. The problem is that I deploy the app with a specific version, then I bump the version and issue updates. But when the read is done on the config it fails because the version is explicit.
So really all I want is this:
<configSections>
<section name="myoptionsdata" type="my.namespace.OptionsSection, myAssembly" />
</configSections>
I have never once seen an example that includes the extended type values. Every example shows Save() creating type="namespace.class,assembly", and yet that doesn't seem to be the default behavior.
So, with reference to the above quote, where can I find information on managing those "optional" values?
For anyone googling, this is one of the causes of the infamous error below:
Exception: An error occurred creating the configuration section
handler for myoptionsdata: Could not load file or assembly
'myAssembly, Version=1.0.3.0, Culture=neutral,
PublicKeyToken=111222aaaabbb' or one of its dependencies. The located
assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)
(C:\Users\me\AppData\Roaming\product\dir\name.config line 4)
I believe my question is similar to this one which so far has not received any response.
Going "off the menu", I just want to deploy a config file to a specific location (non-default) and allow users to set options in a Tools>Options sort of form. Most apps do this. Is there any easy and commonly accepted way of doing this? I should note that my app is an Outlook Addin, and I do my config file like this because I want to store addin settings in an addin-specific config file rather than anywhere near Outlook configs.
The assembly that contains your custom configuration section has a strong name. Strong-naming an assembly explicitly prevents the kind of in-place version upgrade you want to do. Remove the strong name from that assembly and the assembly loader will stop caring what version it is.
Let's say we have Assembly1 and Assembly2.
Assembly2 is a C# class library used by Assembly1.
Web and Service References are configured and stored in Asembly2/app.Config.
Moreover, the EF connection string(s) are in Assembly2/app.Config.
When I use Assembly2 in Assembly1, the Assembly2 config file is not used. In fact, in that scenario, only the Assembly1 configuration appears accessible through default means.
As a result, I have to copy the Assembly2 config contents into the Assembly1 config.
This has worked for me for many projects.
Is there another way? A better way?
It seems wrong to have repeating configuration data.
Do you have a recommendation or technique that works?
Thank you.
You need to apply changes to the config file of entry point exe assembly. Class library assembly (dll) config files are never used. They are made by Visual Studio so you could easily copy the settings to exe config files if needed.
Bellow is example of the config file for exe assembly that has both, settings from class library ClassLibrary1 and settings from the exe assembly MainAssembly. You can see that both connection strings are in one connectionStrings settings. However, if you need to set other settings, beside connection string, you need to add extra section.
If you are already using this technique, this is correct way to go. This technique is flexible. For example if you have more than one project having the same connection strings on one box, you could specify the connection strings in machine.config file. You can also override the settings in some projects if needed.
<?xml version="1.0"?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings"
type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<!--This section declaratrion pasted here from dll conifg file -->
<section name="ClassLibrary1.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
requirePermission="false" />
<!--This section declaratrion was here in the first place -->
<section name="MainAssembly.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
requirePermission="false" />
</sectionGroup>
</configSections>
<connectionStrings>
<!--This connection string was here in the first place -->
<add name="MainAssembly.Properties.Settings.MainAssemblyConnectionString"
connectionString="MainConnectionStringValue" />
<!--This connection string pasted here from dll config file -->
<add name="ClassLibrary1.Properties.Settings.LibraryConnectionString"
connectionString="LibraryConnectionStringValue"
providerName="" />
</connectionStrings>
<applicationSettings>
<!--This settings section pasted here from dll config file -->
<ClassLibrary1.Properties.Settings>
<setting name="LibrarySetting"
serializeAs="String">
<value>LibrarySettingValue</value>
</setting>
</ClassLibrary1.Properties.Settings>
<!--This strings section was here in the first place -->
<MainAssembly.Properties.Settings>
<setting name="MainAssemblySetting"
serializeAs="String">
<value>MainSettingValue</value>
</setting>
</MainAssembly.Properties.Settings>
</applicationSettings>
</configuration>
A DLL (or another referenced assembly) is not meant to carry it's own app.config, but rather have everything configured by the caller. So everything should go into the app.config of the exe.
Consider for example a shared data access library that needs connection strings to the database. The library should be possible to use from a variety of applications with different connection requirements. Having the connection string tied strictly to the shared library wouldn't work, it has to be done at the client using the library.
It is possible to put systemwide settings that affect all applications running on a machine in the machine.config file, but use that approach with caution as it will affect all applications on the machine.
I am trying to read StartingMonthColumn and CategoryHeadingColumn
from the below app.config file using the code
ConfigurationSettings.AppSettings["StartingMonthColumn"]
but it is returning null, also ConfigurationSettings.AppSettings.Count returns zero
Please help me to read this in my windows application
<configuration>
<configSections>
<sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="CTARepository.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
<userSettings>
<CTARepository.Properties.Settings>
<setting name="Setting" serializeAs="String">
<value />
</setting>
</CTARepository.Properties.Settings>
</userSettings>
<appSettings>
<add key="StartingMonthColumn" value="7"/>
<add key="CategoryHeadingColumn" value="1"/>
</appSettings>
</configuration>
ConfigurationSettings.AppSettings is obsolete, you should use ConfigurationManager.AppSettings instead (you will need to add a reference to System.Configuration)
int value = Int32.Parse(ConfigurationManager.AppSettings["StartingMonthColumn"]);
If you still have problems reading in your app settings then check that your app.config file is named correctly. Specifically, it should be named according to the executing assembly i.e. MyApp.exe.config, and should reside in the same directory as MyApp.exe.
Just for the future reference, you just need to add System.Configuration to your references library:
ConfigurationSettings.AppSettings is deprecated, see here:
http://msdn.microsoft.com/en-us/library/system.configuration.configurationsettings.appsettings.aspx
That said, it should still work.
Just a suggestion, but have you confirmed that your application configuration is the one your executable is using?
Try attaching a debugger and checking the following value:
AppDomain.CurrentDomain.SetupInformation.ConfigurationFile
And then opening the configuration file and verifying the section is there as you expected.
Try:
string value = ConfigurationManager.AppSettings[key];
For more details check:
Reading Keys from App.Config
The reason is simple, your call to ConfigurationSettings.AppSettings is not returning the required config file. Please try any of the following ways:
Make sure your app config has the same name as your application's exe file - with the extension .config appended eg MyApp.exe.config
OR you can use ConfigurationManager.OpenExeConfiguration(Assembly.GetExecutingAssembly().Location).AppSettings["StartingMonthColumn"]
Hope this helps
This:
Console.WriteLine( "StartingMonthColumn is {0}", ConfigurationManager.AppSettings["StartingMonthColumn"]);
works fine for me.
Note that ConfigurationManager is in the System.Configuration namespace (so you'll likely want a using System.Configuration; statement), and that since what you read in has a string type you'll need to parse what you read in to use it as a number.
Also, be sure you set system.configuration.dll as a reference in your project or build script.
Try to rebuild your project - It copies the content of App.config to
"<YourProjectName.exe>.config" in the build library.
Also add the key "StartingMonthColumn" in App.config that you run application from, for example in the App.config of the test project.
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.