Nowadays, when incorporating database support into a .NET application , its common practice to use the Microsoft Enterprise Libraries. Since we are developing our application in Visual Studio 2008, we opted to use the most current version (4.1) of the Enterprise Libraries.
The application configuration file consists of three sections that define the target database and connection criteria as shown below:
The onfigSections ties the attribute name="dataConfiguration" to the Enterprise Libraries.
The <connectionStrings> section defines one or more connection strings that specify which database to connect to, logon credentials, machine source, etc.
Lastly, the dataConfiguration ties the Enterprise assemblies to a specific connection string specified by defaultDatabase="ConnectionStringName".
If the defaultDatabase name does not match a connection string, the following error will result:
12/21/2009 14:20:18 : [83c] [_ERROR_]Caught in: SomeWebServer::InitServer
Exception in: D:\ DBLayer\ DB.cs set_ConnectionString(177,4): The type initializer for 'DBLayer' threw an exception.
When Things Go Horribly Wrong
The client I am at decided that the app.config file was not to be deployed with the standard setup, but rather would be generated from XSLT scripts and deployed on a per machine basis. That seemed like a reasonable approach, but they didn’t test it until we were ready to deploy to production. I’m sure you can guess what happened next.
12/21/2009 14:20:18 : [83c] [_ERROR_]Caught in: SomeWebServer::InitServer
Exception in: D:\ DBLayer\ DB.cs set_ConnectionString(177,4): The type initializer for 'DBLayer' threw an exception.
My first reaction was to check the connection strings and the defaultDatabase name. They were a spot on match.
It gets worse.
Typically when using the Enterprise Libraries developers include and deploy the pre-built assemblies that come with the package. Unfortunately that means incorporating the individual projects into our solution.
The customer did not like this solution as it changes the binary footprint of the application even though we assured them it was only temporary.
XML Gotchas
It's obvious that there were differences between my app.config file and the resulting XSLT generated file. It's been my experience in the past that these problems are often caused by non-printable characters in the text files. So the obvious thing to do was to look at the app.config and the XSLT file in a binary editor.
When I opened up the app.config file in binary mode, I was surprised to see 3 bytes that preceded the first printable characters…
What are those? And more to the point, why don’t they show up as ‘.’ or some other funny characters?
Those turn out to be what is known as a Byte Order Mark (BOM).
The byte order mark (BOM) is a Unicode character used to signal the endianness (byte order) of a text file or stream. Its code point is U+FEFF. BOM use is optional, and, if used, should appear at the start of the text stream. Beyond its specific use as a byte-order indicator, the BOM character may also indicate which of the several Unicode representations the text is encoded in.
In prior versions of the Visual Studio IDE going back to 2002, the app.config file is produced as straight XML. In Visual Studio 2008, the editor now adds the BOM to the beginning of the file. The 4.1 parser for the Enterprise Libraries expect the BOM to be the first thing to appear in the app.config file. The XSLT scripts were not coded to insert this byte sequence.
That should have been the end of the story. Of course, there was one more catch… When developers edit the app.config file, they typically use the IDE’s XML editor. When tags don’t match, the IDE will highlight the offending tags with a red squiggle line as shown below:
When the XSLT scripts generated the configuration files, we only looked at them in Notepad. Without the aid of the red squiggle lines, we couldn’t see the XML errors that crept in. One I used the IDE to look at the files, the mistake was obvious. In this case, the Transport section is missing the ‘/’ in the terminating <value> tag.
Lesson learned.
