One of the more fun things I get to do right now is design and build a brand spanking new application foundation for a very large ASP.NET application. This is extra positive as this new foundation is being hashed out for a very small project, but will grow and evolve over time so when the big project comes along a lot of plumbing should already be in place. Enterprise Library is going to be one of the major components of the new foundation.
Knowing this, I am building a number of class libraries and namespaces to segregate various pieces of functionality. Along came the expected “foundation.data” class library and I hit a wall; Enterprise Library uses web.config (or app.config for WinForms) to store a key to where the rest of the Enterprise Library configuration is stored. Foundation.data is just a class library and I really didn’t want to make it into something more than just that. Besides, there is likelihood that this level of foundation would be used on both WinForms and Web apps. No chance of hacking a solution with app.config or web.config.
I found my answer in a couple of blog entries relating to deploying Enterprise Library with beta2. Not having played with it much yet I can’t comment on why this was needed, but James White came up with a number of source changes to make everything work in this post. I messed up on implementing it the first time, placing my filename replace too late in the method. I eventually downloaded James’s full beta 2 build of Enterprise Library and checked his code there. That is displayed in its entirety below:
ConfigurationBuilder.cs :: LoadMetaConfiguration
private void LoadMetaConfiguration(string configurationFile)
{
configFile = new ConfigurationFile();
string machineFilename = MachineConfigurationFile;
// make sure we don't load the machine file twice
if (string.Compare(configurationFile, machineFilename, true, CultureInfo.InvariantCulture) != 0)
{
ConfigurationFile machineConfigFile = new ConfigurationFile();
bool machineFileExists = machineConfigFile.Load(machineFilename);
if (machineFileExists)
{
configFile = new ConfigurationFile(machineConfigFile);
}
}
configurationFile = configurationFile.Replace("web.config", "enterpriseLibrary.config");
configFile.Load(configurationFile);
CreateMetaConfigChangeWatcher();
this.currentConfigFileName = configurationFile;
InitializeConfiguration(ReadMetaConfiguration());
}
The new configuration file (enterpriseLibrary.config) now contains only the Enterprise Library specific settings, looking something like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="enterpriselibrary.configurationSettings" type="Microsoft.Practices.EnterpriseLibrary.Configuration.ConfigurationManagerSectionHandler, Microsoft.Practices.EnterpriseLibrary.Configuration, Version=1.0.0.1, Culture=neutral, PublicKeyToken=null" />
</configSections>
<enterpriselibrary.configurationSettings xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" applicationName="Application" xmlns="http://www.microsoft.com/practices/enterpriselibrary/08-31-2004/configuration">
<configurationSections>
<configurationSection xsi:type="ReadOnlyConfigurationSectionData" name="dataConfiguration" encrypt="false">
<storageProvider xsi:type="XmlFileStorageProviderData" name="XML File Storage Provider" path="dataConfiguration.config" />
<dataTransformer xsi:type="XmlSerializerTransformerData" name="Xml Serializer Transformer">
<includeTypes />
</dataTransformer>
</configurationSection>
</configurationSections>
<includeTypes />
</enterpriselibrary.configurationSettings>
</configuration>
Note that the actual name and location of the new configuration file is entirely up to you. James originally suggested placing it in its own folder, for now I am opting to keep it in the main application directory.
Here are a couple of notes on this whole process:
- The Enterprise Library configuration tool filters only for app.config and web.config, so you will need to filter for all files. You have the source to that application and can change it in your spare time if it really annoys you.
- I changed all my revision numbers in Enterprise Library to differentiate it from the original release.
- Changes made to enterpriseLibrary.config (or your new configuration file name) will not automatically reset a web application. This likely means more during development than production, just something to note.
- I have not yet tested to see if you can nest these new configuration files in subdirectories the way you can with web.config files. For example, if a admin subdirectory needed additional configuration settings the main application would not want/use. Not sure I really care as I haven’t yet found the need to nest web.config files.
Would be nice if future releases of Enterprise Library will make this a tad easier. Hope this helps someone else, as it was a bear to find and implement just right. Thanks James White and Scott Densmore!!!