While participating on the BizTalk Forums recently I came across a thread where the OP had problems with working on Logging using the Enterprise library in an Biztalk environment. The thread can be found here. While discussing the issue, OP posted that he had uninstalled the ESB toolkit from the environment and the logging framework started working. Well the comment did spark some old memories for me and I remembered the time I came head to head with the issue.

My Problem Statement

In one of the projects that I worked on, the environment was BizTalk 2010 server environment with the supported ESB Toolkit 2.1. The BizTalk server also hosted an application which was used as REST api wrapper for the BizTalk service ( Since the capability of consuming the REST apis is not there out of the box for BizTalk 2010). In that particular layer there was an integration with a third party vendor, where the dlls shared by them had a dependency on the Enterprise Library Framework 5.0 . As was the case in the thread mentioned above, we tested the code on the dev box where there was no Biztalk and it worked fine, but after deployment to the UAT servers, the whole third party integration crashed.  Being unaware of the relation between the ESB toolkit 2.1 and the Enterprise Library Framework 5.0, we spent lot of days pondering over the issue and had to finally move the integration out of the BizTalk environment. There are some blogs written over this but I could not find a technet wiki article dedicated to this particular issue so decided to contribute this. There is a comprehensive  ESB survival guide article here

The Real Issue

The ESB Toolkit 2.1 when installed write the Enterprise Library Framework entries in the Machine.config of the server which at the end of the day overrides any Enterprise Library Framework 5.0 entries made to the local application config files. ESB Toolkit 2.1 makes following entries in the machine.config

<section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=,Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add name="ESB File Configuration Source" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=,Culture=neutral, PublicKeyToken=31bf3856ad364e35" filePath="C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\esb.config" />
 <add name="ESB SSO Configuration Source" type="Microsoft.Practices.ESB.SSOConfigurationProvider.SSOConfigurationSource, Microsoft.Practices.ESB.SSOConfigurationProvider, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" applicationName="ESB" description="ESB SSO Configuration" contactInfo="" userGroupName="BizTalk Application Users" adminGroupName="BizTalk Server Administrators" />

Depending upon whether the server is 64 bit or 32 bit, the machine.configs can be found on the following paths

For 32 bit:
For 64 bit

So whenever an application using the Enterprise Library 5.0 is deployed on the BizTalk environment which has ESB toolkit 2.1 configured, the application crashes leaving the developer and admin in bewilderment

​Solution For The Issue

A lot of debate has happened back in the day over the issue of ESB 2.1 crashing the Enterprise Library Framework 5.0 application and like the debate, it is said that no fix is there for this issue. Well after going some of the blogs and MSDN threads, I found out that in some cases the issues were resolved while in some case some work around was to be implemented. Since I could not find a wiki article consolidating the links, I have posted the links below to threads and blogs on this scenario.

Note: The views mentioned in the blogs or the threads are the opinions of the OPs 
In the end some have solved the issues while some have to find a workaround for it.
Please add more information if it is found so that this article can serve as a repository for the future and people in trouble can find a source to look at.