Customer-extensible configuration
September 15, 2014 Leave a comment
While playing around with custom resources I wondered what ways there are to configure which IResourceManager is used for those generated classes.
As I mentioned before I’m not particularly fond of XML for configuration purposes. But the *.config files are still the most commonly used means to configure a .NET application.
My goal was to allow a developer to configure which of a set of predefined resource managers to use (an obvious choice would be the file based approach with the .NET ResourceManager and maybe a database based implementation) while allowing him to add his own implementations later on. That kind of extensibility calls for an abstract factory approach.
The config file should look something like this
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="i18n" type="Playground.I18nSettingsSection, Playground" />
</configSections>
<connectionStrings>
<clear />
<add name="DEFAULT" connectionString="localhost"/>
</connectionStrings>
<i18n>
<resxManager>
<db connectionStringName="DEFAULT" />
</resxManager>
</i18n>
</configuration>
File 1: What I wanted my App.config to look like
The code behind that solution should be quite simple. Along the lines of:
public class I18nSection : ConfigurationSection
{
[ConfigurationProperty("resxManager")]
public ResourceManagerSettings ResourceManager
{
get { return (ResourceManagerSettings) base["resxManager"]; }
set { base["resxManager"] = value; }
}
}
public abstract class ResourceManagerSettings : ConfigurationElement
{
public abstract IResourceManager GetResourceManager(Type resourceFileType);
}
File 2: What I thought might be a good idea for the code behind
When was anything ever that easy? The whole thing blew up in my face. The underlying problem being that the .NET configuration system cannot create an instance of an abstract class (the ResourceManagerSettings) and you can neither get access to the code where the instantiation happens (it’s a private method somewhere inside ConfigurationElement) nor can you handle it via overriding OnDeserializeUnrecognizedElement in your section class. The element is not truly unrecognized if you decorate the ResourceManager property with the ConfigurationPropertyAttribute so the method would never be triggered. You can remove the attribute but then where do you store the created object? You can’t call base["resxManager"] anymore because there is no longer a ConfigurationProperty with that name. And what if you had more than one “unrecognized element” in that section? You couldn’t assume that you where to create a concrete implementation of your abstract ResourceManagerSettings which would make figuring out which class to instantiate quite a bit harder (remember that you want the developer to be able to extend that solution later).
So I had to figure out another approach. What eventually worked was moving the whole concept up one level in the hierarchy of the config system. Where I formerly used a ConfigurationSection I had to use a ConfigurationSectionGroup as base class. And the ConfigurationElement became a ConfigurationSection.
What I ended up with was an App.config that looks like this:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="i18n" type="Playground.I18nSettingsSectionGroup, Playground">
<!--<section name="file" type="Playground.FileResourceManagerSettings, Playground"/>-->
<!--<section name="null" type="Playground.NullResourceManagerSettings, Playground"/>-->
<section name="db" type="Playground.DbResourceManagerSettings, Playground"/>
</sectionGroup>
</configSections>
<connectionStrings>
<clear />
<add name="DEFAULT" connectionString="localhost"/>
</connectionStrings>
<i18n>
<db connectionStringName="DEFAULT" />
</i18n>
</configuration>
File 3: Actual App.config
And the code behind to match the .config file:
public class I18nSettingsSectionGroup : ConfigurationSectionGroup
{
public const string NAME = "i18n";
private ResourceManagerSettings _ResourceManagerSettings;
public ResourceManagerSettings ResourceManager
{
get
{
if (this._ResourceManagerSettings != null)
{
return this._ResourceManagerSettings;
}
if ((this._ResourceManagerSettings = this.Sections.OfType<ResourceManagerSettings>().SingleOrDefault()) == null)
{
this._ResourceManagerSettings = new FileResourceManagerSettings();
this.Sections.Add(FileResourceManagerSettings.NAME, this._ResourceManagerSettings);
}
return this._ResourceManagerSettings;
}
set
{
ResourceManagerSettings resourceManagerSettings = this.Sections.OfType<ResourceManagerSettings>().SingleOrDefault();
if (resourceManagerSettings != null && !Equals(resourceManagerSettings, value))
{
this.Sections.Remove(resourceManagerSettings.SectionInformation.SectionName);
}
this.Sections.Add(value.SectionInformation.Name, value);
}
}
}
public abstract class ResourceManagerSettings : ConfigurationSection
{
public abstract IResourceManager GetResourceManager(Type resourceFileType);
}
public class FileResourceManagerSettings : ResourceManagerSettings
{
public const string NAME = "file";
public override IResourceManager GetResourceManager(Type resourceFileType)
{
return new ResourceManagerWrapper(new ResourceManager(resourceFileType.FullName, resourceFileType.Assembly));
}
}
File 4: Actual implementation
In the <configSections> part of the .config file I configure the I18nSectionGroup with at most one (!) implementation of the ResourceManagerSettings. If you add multiple implementations the .NET configuration system will instantiate all of them when you read from the file. And now you would have to figure out which one you actually wanted to use. So (by design!) the code above will fail in case you configured more than one ResourceManagerSetting.
If you don’t configure anything the I18nSectionGroup will fall back to the FileResourceManagerSettings. I believe that’s an acceptable default.
When you set the I18nSectionGroup.ResourceManager property at run-time and save the configuration back to disk the correct section type will be persisted in the <configSections> part of your .config file.
So what I got is not exactly what I wanted. If the .NET framework weren’t as uptight about the object creation (the configuration system is by no means the only part of the framework that behaves like that!) the whole exercise would have been a lot easier. To MS’ defense: From the comments in the code of the ConfigurationElement they seemed to have some security considerations going on. Still, they might (at least) have provided a way to influence what type of object should be created if they couldn’t/didn’t want to let you handle the instantiation itself.
Anyway. You now have a means to configure where your resources are loaded from and if you want to add another source (like RavenDB for example) you can always do so with little effort. If you either mark your resource classes with an interface or a custom Attribute or decide on a naming convention it is really easy to brew up a little reflection code that sets the static ResourceManager property at application start-up.
Outlawtrail - .NET Development 