Configuration Manager Tool doesn't see Settings

Aug 2, 2007 at 1:51 PM
Hello! I have an application which consumes web services. I configured the web service proxy to pull the URL based on a setting in the configuration file. This is done in VS 2005 by changing the property "Url Behavior" to "dynamic". Follows the part added to the <configSections> element :

<sectionGroup name="applicationSettings"
type="System.Configuration.ApplicationSettingsGroup, System,
Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="LetterPrint.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System,
Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false"/>

the <section> looks like this:

<applicationSettings >
<LetterPrint.Properties.Settings >
<setting name="LetterPrintLetterControlServicesLetterControlServices"

I thought it will be helpful to use the Configuration tool to access this section (as it did it with others) to apply to it EnvironmentOverrides. But the tool seems not to perceive this section at all.

A section like the above is also created when entering data in Settings, under app Properties.

Thanks in advance.
Aug 2, 2007 at 2:07 PM

The config tool works with the standard "appSettings" section, not these settings.

Aug 2, 2007 at 2:32 PM

Hi, Fernando, thank for your reply.

As I see it, these "non standard" application settings are generated by Microsoft.

Secondly, there is a type attribute. Is this not enough for the Tool to find out how to deal with the section ?

Aug 2, 2007 at 3:16 PM

I'm afraid these settings are not as simple as it may seem.

For starters each setting file is mapped to a new configuration section having the name of the settings type as its section name, while the "appSettings" section always has the same name. While you can get all the sections (and they can be a lot) through the Configuration class, that's not the way the tool works; each node looks for a specific section name.

The type attribute in the XML is used during deserialization, but it could be argued that managed the type of the section object could be used as a key. But for the reason described above, it's not useful.

Finally, I'd argue that in order to have a user experience comparable to the one provided by VisualStudio's Settings Editor the metadata in the .settings file should be used; this doesn't fit in the way the tool works.

It's unfortunate that this precludes the use of the environmental overrides.

Oct 16, 2007 at 1:33 PM
this makes this tool pretty useless. What's the point in only being able to manage "SOME" of the settings in the tool?? how is one supposed to merge the rest? as far as I'm concerned, this might aswell be done by XSLT or other means. You're not required to make a fully bullet-proof way of editing these settings (appSettings are dead since release of .NET 2.0, at least for me), but any support of it in the tool would already be apprechiated.

Why does the web-deployment-project provide a solution? Yes, it's not 100% either, but it's better then nothing.