I am using the Configuration Section Designer for .NET to build a simple ConfigurationElementCollection
. It appears that everything builds just fine and the code is automatically generated since the sub-elements are visible with Intellisense.
Unfortunately, even though I have added elements to the collection in the configuration section, they do not exist at run-time; it shows the collection's Length
property to be 0 - i.e. the collection is empty even though, as you can see in my example XML, I have clearly put them there:
<logParserSettings xmlns="LogParser">
<domainControllers>
<domainController ID="0" name="Local" serverType="Local" enabled="true"/>
<domainController ID="1" name="DC1" serverType="WindowsServer2003" enabled="false" />
<domainController ID="2" name="DC2" serverType="WindowsServer2008" enabled="false" />
</domainControllers>
</logParserSettings>
ConfigurationSection
, a ConfigurationElementCollection
, and a ConfigurationElement
- there are no additional configuration elements/sections/groupsSingleton
property, but neither the singleton instance nor an instance of the settings class seem to workIs Key
property is set to true, and all other attributes are marked true for Is Required
Has anyone ever run into this? If so, what change do I have to make to get this to work as intended?
Well, I grossly overcomplicated the true issue by specifying the problem down to a specific element, when it turns out not even a simple test attribute on the ConfigurationSection
would return an expected value. I also realized that I couldn't access AppSettings
, which resulted in a raging clue.
The ultimate cause? The project was compiled as a class library. Config files are only available at the application level. Since I was using NUnit to run the tests, the configuration file from the test project was overriding the development one for the class library. This is probably obvious to any developers who are not stuck in ASP.NET land.
By adding the following configSection
to the app.config
within the test project:
<section name="customConfigSection" type="ClassLibraryNamespace.SettingsClass, ClassLibraryNamespace"/>
and filling in the corresponding section, the data could be accessed as expected.
Hopefully, this will save someone hours of debugging.