I am giving a lecture about Enterprise Library 2.0 and 3.0 for a customer later this month, and spending the last few days building a demo application (Expect more details and posts about this later).
I ran into a problem with the configuration tool the minute I started working with it: The configuration editor always place the assembly definitions of the assembly as signed assemblies. For example:
<section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=220.127.116.11, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
Running the application (Web or Win) always raised the following exception: "Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Logging, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)".
I even recorded a video myself creating a sample project, calling for help.
Thanks to Olaf Conijn and Hanz Zhang (Test Lead for Enterprise Library), I can now get back to work. It turns out that when you install Enterprise Library 3.0 (or 3.1), you actually get two distinct copies of the library. One copy is in the form of pre-compiled binaries – by default these get installed to "C:\Program Files\Microsoft Enterprise Library 3.1 – May 2007\bin". The other copy is in the form of source code, which by default will be compiled and the assemblies coped to "C:\EntLib3Src\App Blocks\bin".
While both copies of Enterprise Library contain identical code, there is one critical difference: the pre-compiled binaries are strong-named (with a Microsoft key that we do not ship), and the assemblies compiled from the source code are not initially strong-named. So as far as .NET is concerned, these two sets of assemblies are completely different and completely incompatible with one another.
I wish I had read Tom Hollander's post: Avoiding configuration pitfalls with incompatible copies of Enterprise Library, that talks about this issue.
When I created the solution, I referenced the assemblies in "C:\EntLib3Src\App Blocks\bin", while the integrated configuration editor added settings using the singed assemblies in "C:\Program Files\Microsoft Enterprise Library 3.1 – May 2007\bin". In order to solve this, I had to set the EnterpriseLibraryConfigurationSet property to "Entlib3Src" in the solution properties.