2

I'd like to edit application-specific settings by using the IIS 7 Configuration Editor. The settings are stored in an applicationSettings section, the kind automatically added for you when using Visual Studio to add settings to a project. My section looks like this:

<applicationSettings>
    <My.Custom.Properties.Settings>
      <setting name="SomePath" serializeAs="String">
        <value>D:\Folder\SubFolder</value>
      </setting>
    </My.Custom.Properties.Settings>
</applicationSettings>

So, by following directions from here, and after a lot of trial and error, I am able to load the section into the IIS editor. I can see (and edit) the attributes on the setting element. I can also see the value element, but the folder path inside it is not loaded and it can't be edited, which is what I need! The schema I have added to IIS looks like this:

<configSchema>
     <sectionSchema name="applicationSettings/My.Custom.Properties.Settings">
       <collection addElement="setting">
         <attribute name="name" type="string"></attribute>
         <attribute name="serializeAs" type="string"></attribute>
         <element name="value"></element>
       </collection>
     </sectionSchema>
</configSchema>

Has anybody succeeded in doing what I'm trying to do, or, is there a way around this that doesn't involve going back to the old appSettings section?

Community
  • 1
  • 1
Paul
  • 420
  • 1
  • 5
  • 18

1 Answers1

2

Having found no other alternative, I opted for changing the schema of the applicationSettings section so that the value of a setting element is stored as an attribute of the element, not another element within it, which is what the IIS Editor likes. So, my settings now look like this:

<setting name="SomePath" serializeAs="String" value="D:\Folder\SubFolder">
</setting>

This, of course, meant implementing my own settings provider (see "Custom Settings Providers" here) so that I could read from the new attribute. This is not too hard, and it's even less so if you inherit from the LocalFileSettingsProvider that comes with .NET. Moreover, if you don't plan on changing settings at runtime, then you only need to implement the GetPropertyValues method.

The downside with this approach is that it complicates design-time support from Visual Studio, since the Settings designer won't recognize the new schema, and I found no way of telling it to use the custom provider. The good news is that the designer will load after giving you an error about this, so you can still use it to define settings. However, it will overwrite your config file with the default schema when you save. My solution to this was to create a piece of JScript that runs on Visual Studio's prebuild event, and that will modify the settings changed by Visual Studio to conform to my schema. This page was very useful when coding the script.

Tips for implementing the custom provider:

  • I used the AppDomainSetup.ConfigurationFile property to get to my config file.
  • When loading settings, just set the SettingsPropertyValue.SerializedValue property and the framework will deserialize the actual value for you.
  • To make the application use the provider at runtime, click an individual setting on the designer and, on the Properties pane, enter the provider's class name on the Provider field. To specify the provider for all settings entered through the designer, click on the View Code button and add the SettingsProviderAttribute to the class.
Paul
  • 420
  • 1
  • 5
  • 18