I'm having a weird problem on deployment while trying to use Microsoft Enterprise Library's Data Access Application Block 4.1. I get the following Unhandled Exception when trying to use the element of the web application that utilizes the DAAB:
Exception information:
Exception type: BuildFailedException
Exception message: The current build operation (build key Build Key[Microsoft.Practices.EnterpriseLibrary.Data.Database, DBNAME]) failed: The type initializer for 'Microsoft.Practices.EnterpriseLibrary.Data.Database' threw an exception. (Strategy type ConfiguredObjectStrategy, index 2)
My web.config has the following section for connectionStrings:
<connectionStrings configSource="data.config" />
And the data.config contains an entry for the DBNAME referenced in the exception:
<?xml version="1.0"?>
<connectionStrings>`
<add name="dbname"
providerName="System.Data.SqlClient"
connectionString="[valid information here]" />
</connectionStrings>
I know the connection string is valid because the portions of the app that aren't using DAAB for data access are using the same connection string with no problems. Additionally, things are working fine on my development machine, as well as the machines of the other developers. This is only happening on deployment to the production servers and isn't even specific to the "release" build since that version runs fine on my local machine as well.
I suspect that it is probably a configuration issue with the production servers, but I haven't been able to figure out what it might be. The MSDN article on deploying Enterprise Library mentions that an xcopy deployment of the assemblies should work and I'm including them in the /bin folder, so I'm not sure where to go from there. Any ideas?
Finally figured this out. Enterprise Library 4.1 requires Framework 3.5 and even though we are still targeting Framework 2.0 for our application, 3.5 is installed on our development machines by virtue of using Visual Studio 2008. We did not, however, have Framework 3.5 installed on our production servers and the problem disappeared after doing so.
The puzzling thing is that I am explicitly targeting 2.0 for compilation in all projects in my solution including the one that relies on the Enterprise Library, so you'd think referencing an assembly that requires 3.5 would at least produce a warning on compilation. Oh well.