Could not load file or assembly "Microsoft.Practices.EnterpriseLibrary.ExceptionHandling

Question

I get this error below when I add the Enterprise library 5.0 MS.Practices.EnterpriseLibrary.ExceptionHandling.dll file for my wcf application.

An error occurred creating the configuration section handler for the Handling exception: the file or assembly "Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version = 2.0.0.0, Culture = neutral, PublicKeyToken = null" or one of its dependencies could not be loaded. The located assembly manifest definition does not match the assembly reference.

<exceptionHandling> <exceptionPolicies> <add name="Global Policy"> <exceptionTypes> <add name="Exception" type="System.Exception, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" postHandlingAction="None"> <exceptionHandlers> <add name="Wrap Handler" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WrapHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling" exceptionMessage="Global Message." wrapExceptionType="ExceptionHandlingQuickStart.BusinessLayer.BusinessLayerException, ExceptionHandlingQuickStart.BusinessLayer" /> <add name="Custom Handler" type="AppMessageExceptionHandler, ExceptionLibraryForWCF"/> </exceptionHandlers> </add> </exceptionTypes> </add> <add name="Handle and Resume Policy"> <exceptionTypes> <add name="Exception" type="System.Exception, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" postHandlingAction="None"> <exceptionHandlers/> </add> </exceptionTypes> </add> <add name="Propagate Policy"> <exceptionTypes> <add name="Exception" type="System.Exception, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" postHandlingAction="NotifyRethrow"> <exceptionHandlers/> </add> </exceptionTypes> </add> <add name="Replace Policy"> <exceptionTypes> <add name="SecurityException" type="System.Security.SecurityException, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" postHandlingAction="ThrowNewException"> <exceptionHandlers> <add name="Replace Handler" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.ReplaceHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" exceptionMessage="Replaced Exception: User is not authorized to peform the requested action." replaceExceptionType="System.ApplicationException, mscorlib"/> </exceptionHandlers> </add> </exceptionTypes> </add> <add name="Wrap Policy"> <exceptionTypes> <add name="DBConcurrencyException" type="System.Data.DBConcurrencyException, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" postHandlingAction="ThrowNewException"> <exceptionHandlers> <!--<add name="Wrap Handler" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WrapHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling" exceptionMessage="Wrapped Exception: A recoverable error occurred while attempting to access the database." wrapExceptionType="ExceptionHandlingQuickStart.BusinessLayer.BusinessLayerException, ExceptionHandlingQuickStart.BusinessLayer" /> --> </exceptionHandlers> </add> </exceptionTypes> </add> </exceptionPolicies> 

Below is my web.config declaration for my exception handling ->

Answer 1

Your web.config is not actually in the message.

In any case, you have a link to Entlib 2.0 in your configuration file. You need to update to indicate the version number of Entlib 5 and the public key token. This is probably in your element, but if it is there, I would not be surprised if the rest of your file also had the wrong version.

[update further thoughts]

Actually, based on the error message, there is one more possibility - the runtime finds assembly 2.0 instead of assembly 5.0 when it goes to load. Double-check all assembly references and check the bin directory - make sure that it has the correct assembly.

You can also try running the fuslogvw tool on a web server - it will tell you what assemblies were executed at runtime, and where they were looking for.

Answer 2

I had a similar problem caused by source control. I checked in the old copy of the project file after the employee updated the project. I just found a project that referenced the assembly / project link by mistake, deleted the link, re-added the link and rebuilt the solution. lotto.