Enterprise Library Oddities: Why does the DAAB always show up in my configuration?

If you've played with Enterprise Library for .NET Framework 2.0, you may have wondered why the Data Access Application Block always shows up in the configuration tool when you open an application's configuration file, even if you didn't ask for it - and that it seems to be impossible to get rid of:

The behavior is indeed strange, and it wasn't a deliberate design decision - rather it was a consequence of a few other changes we made to better align Enterprise Library with new features in .NET Framework 2.0.

First, Enterprise Library now uses System.Configuration to load and save configuration. That means that all of the features of System.Configuration can now work with Enterprise Library, even if some of these are somewhat unexpected. One of these features is that configuration data from machine.config is automatically merged into each application's view of configuration. You'll see in a moment why this is important.

Second, the Data Access Application Block now uses .NET's new <connectionStrings> section to manage the connections used by the block - the same configuration section that is used by other .NET features. The DAAB does still have its own section it uses for more advanced features such as specifying a default database or custom provider mappings, but the block can work without these settings.

Finally, by default, the machine.config file contains a <connectionStrings> section including one default connection, called LocalSqlServer - which points to (I'm sure this will be a shock to you), an instance of SQL Server on your local machine.

Since I'm no Agatha Christie, you've probably solved the mystery by now. Whenever the Enterprise Library Configuration tool opens an application's configuration file, System.Configuration dutifully merges machine.config with the requested file, and gives the result back to the tool. In fact it doesn't even bother telling the tool which sections came from where, which is why we can't hide the LocalSqlServer section or show it as read only. As far as the tool (or you, until you learnt the awful truth) knows, this section is a part of the application's configuration file. However if you change or delete this connection string using the tool, System.Configuration won't actually persist the changes back to the file, since it's machine.config and you have no business messing with it (not that it will tell you this, of course!)

Of course, if this behavior really bothers you, you can open up machine.config with notepad and remove this section, and it will bother you no more. However, the presence of this section doesn't cause any real harm - in fact you can indeed call DatabaseFactory.CreateDatabase("LocalSqlServer"), so arguably you should see it every time you open up an application's configuration file.

Stay tuned next time as we unveil more Enterprise Library oddities... :-)

This posting is provided "AS IS" with no warranties, and confers no rights.