Develop Reference

Is it possible for an Azure Role ConfigurationSetting to be optional?

My configuration code is setup in a way that default values are provided, and configuration files can be used to override these defaults.
For Azure Worker Roles I use the CloudConfigurationManager to read the configuration from the ServiceConfiguration.*.cscfg files for overriding the defaults.
A common reason for overriding the defaults is to provide different storage (blob,table,queue,etc) names during testing.
Unfortunately as far as I can tell, once a Setting has been defined in the ServiceDefinition.csdef file it must be provided in all ServiceConfiguration.*.cscfg files.
This wipes out the advantages of having less configuration to create and reducing the chance of errors creeping in while creating that configuration.
Is there a way to make a Setting optional?
Or is there another alternative place I can get deployment-specific configuration values from that works the way I want?

How to use environment dependent app.config file

We are a group of C#/.NET 4.5 developers working on the same application.
The application has a set of configurations related to each developer machine, like the connection string to the DB, network related settings (proxies, IPs, credentials) and a LOT MORE.
Because the application has grown we are incurring in a lot of environment related configurations like for example:
If this is MyPC then load the connection string for my PC.
If this is the XDeveloperPC then specify proxy’s settings.
Also if new developers leaves or join the group, then the process to update the file becomes a total head ache. Maintaining the file has become very hard and is a possible source of bug and errors.
I was thinking in having specific app.config files related to each developer environment like:
app_MyPC.config
app_XDeveloperPC.config
And when the application builds or executes then specify which one to load as if it where the default app.config of the application. Then, when the application or any class or method refers to a given configuration (like the connection string) is access to this configuration file as if it where accessing to the app.config default file.
I would not want to create a Configuration class that builds immediately when the application starts because then I should have references from every place to this class and the application is quite large, with a bunch of projects and dlls.
I rather prefer to hear some opinions and what do you think should be the best way to achieve this.
Is it possible to achieve this?
How?
Do you know a better approach?

FYI, please note that .NET only loads one config file for the whole application. You could try multiple config files something as like specified here,
Multiple App.Config Files in .NET Class library project
Hope this helps...

You can specify sections of app.config to be loaded from another file. See this answer
However, you might have to customize the above solution, the app.config files and the way configs are organized.
Another approach is to use a custom settings file instead of app.config. This will need some code change to use the config file. This config can either be an XML or a JSON file (JSON is easy to deal with). You can use an inheritance model wherein generic settings come from one file, specific settings come from another file and so on. Also, you can load settings from such file at runtime and change application behavior on the fly.
If you decide to use custom config file, and if you already have lot of code written considering App.config file, you can abstract the app.config calls to a method and let that method deal with where to pull the settings value from. That way you can minimize the code change and keep everything tidy.

Maybe you can use the machine.config file (C:\Windows\Microsoft.NET\Framework\your Framework version\Config\machine.config)

C# custom configuration versioning

I have implemented a custom file configuration, that uses custom sections, using C#.
The main issue i have is with implementing some kind of version aware configuration loader.
Confgiurations change, but we need to make them usable anyway.
Is there any documentation that points in the direction of having some kind of versioning in configurations?
I'll give you two examples on what my issues are:
- key["key1"] changes from boolean type to int type.
- key["key2"] mandatory ceases to exist
thanks.

My tendency would be to add some kind of version header to the configs and keep a history of their schemas in the app. It could be troublesome in some ways, but at least you don't have to guess what an old value meant.

You could have the concept of default values for each setting. If you introduce a new setting and an old config file doesn't have it then it would use the default value. Similarly, if you remove a setting from the code then its existence in the config file would be harmless, it would just be ignored.
If you want to change how a given setting works (the type or the format) then it's a little more tricky. You could try to parse the value and if it's not in the right format you could ignore it and use the default value.

c# pattern for two applications sharing a configuration file

I have two applications that have many common configuration properties. When a configuration property of one changes, I want the other to change as well. Does anyone have a sensible way to accomplish this before I start off down the wrong track?
EDIT: I'm using .NET 2.0

You can create and reference a common configSource for the configuration section(s) involved. For instance, if you wanted a common set of AppSettings, copy your current appSettings to a new file (say appSettings.shared.config) and replace them in both app configs with this:
<appSettings configSource="appSettings.shared.config"/>
Here's more documentation: http://sunali.com/2008/01/23/configsource-property-dividing-configuration-files-into-pieces/
Far as I know, this cannot be done for an entire file, only sections, and each section will need its own file (and the section must still be declared in the configurationsections element of the app.config). But, this has a number of really cool uses; for instance, you can separate your connection strings into files geared towards different environments (local, development, testing, staging, production) and by changing one filename in one place you've now pointed your app at the different environment.

One easy way to accomplish this is to use the configSource attribute in the app.config in both applications, and point this to a common file. Bingo, change one file, all apps are updated.
Check the MSDN documentation on it here.

there are a couple of different ways you could do this:
use the registry
use a config file in a common location
use a configuration table in a database

System.Configuration: Question on the Configuration.Save method

What is the difference between configuration.Save(ConfigurationSaveMode.Modified, true) and configuration.Save()?
Background: I have a programme, where I manipulate a web.config, which I use for configuring WCF Services. I load it into a Configuration object, change some attributes and save it back. When I use configuration.Save(ConfigurationSaveMode.Modified, true) I get an Exception like this:
"It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level..."
When I use configuration.Save(), then it works! The reason for the exception may be the section <serviceActivations> in my web.config (the exception points to this section)

The default parameters to Save are:
Save(ConfigurationSaveMode.Modified, false);
So the only difference would be that you force saving the configuration, even if it was unchanged. See http://msdn.microsoft.com/en-us/library/ms134089.aspx for more information.

Why woyld you write configuration.Save(ConfigurationSaveMode.Modified, true) when:
ConfigurationSaveMode.Modified means:
Causes only modified properties to
be written to the configuration file,
even when the value is the same as
the inherited value.
true means: true to save even if the
configuration was not modified;
otherwise, false.
Isn't the first option the opposite of the second?

ConfigurationSaveMode.Modified only saves the parts of the configuration that are different to the application/system configuration to a user local or roaming configuration (i.e. using ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel) with ConfigurationUserLevel.PerUserRoaming or ConfigurationUserLevel.PerUserRoamingAndLocal).
Since ASP.NET doesn't have user levels (and user isolated storage) this doesn't make sense.
From the documentation is not clear if any of the Configuration.Save overloads will really work in the case of ASP.NET which uses a completely different configuration setting inheritance model to non-ASP.NET .NET applications. In practice using one of the WebConfigurationManager to load the configuration manager is likely to be a necessary pre-condition to saving the file.
Another approach might be to explicitly load a explicitly designated file with ConfigurationManager.OpenMappedExeConfiguration.