Issue with Enterprise Library "Common" dll.

Topics: Building and extending application blocks
Jul 8, 2011 at 11:09 AM
Edited Feb 29, 2012 at 4:16 AM

I have my Solution with "Logging", "Exception" & "Data Access" blocks created in separate projects. I have referred the corresponding dependant Enterprise Library dlls to these projects.

Now when I have included the configuration settings for all these blocks in a sample console application config file. I am getting the below error at this line.

if (EnterpriseLibraryContainer.Current ==  null)

I have referenced all my dlls from the "C:\EntLib50Src\Blocks\bin\Release" folder.

Error Details:

Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common, Version=5.0.414.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Fusion Log:

=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Practices.EnterpriseLibrary.Common, Version=5.0.414.0, Culture=neutral, PublicKeyToken=null
LOG: Appbase = file:///C:/POC/bin/Debug/
LOG: Initial PrivatePath = NULL
Calling assembly : Microsoft.Practices.EnterpriseLibrary.Data, Version=5.0.414.0, Culture=neutral, PublicKeyToken=null.
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\POC\bin\Debug\

LOG: Using host configuration file:
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/POC/bin/Debug/Microsoft.Practices.EnterpriseLibrary.Common.DLL.
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Jul 11, 2011 at 1:26 AM


Can you try referencing from Enterprise Library Installation Path? (C:\Program Files\Microsoft Enterprise Library 5.0\Bin) and see if it solves the issue?


Noel Angelo Bolasoc
Global Technologies and Solutions
Avanade, Inc.

Jul 12, 2011 at 12:23 PM

I tried referencing the modified dlls from the source for all the Enterprise Lib references and it solved this issue. I have set the Public key token to NULL for all the Enterprise Lib config entries. I mean all the dlls are Non-Strong Named and I am fine with that way.