The average BizTalk solution has a large number of DLLs that need to reside in the Global Assembly Cache (GAC). As a result, deploying the BizTalk solution can consume more cycles than is necesary. The time factor becomes apparent during troubleshooting (debugging) BizTalk, when the solution must be frequently rebuilt, redeployed, and restarted.

 

The problem described may be resolved by removing BizTalk DLLs from the GAC and placing them into a common folder. Then the runtime section of the BTSNTSvc.exe.config must be updated to include dependent assembly references to BizTalk DLLs residing in the common folder. Below is the fragment of an updated BTSNTSvc.exe.config runtime section.

<runtime>

 <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

<probing privatePath="BizTalk Assemblies;Developer Tools;Tracking;Tracking\interop" />

<dependentAssembly>

<assemblyIdentity name="Solution.Project.Module" publicKeyToken="909dd514af6267cd" culture="neutral" />

<bindingRedirect oldVersion="1.0.0.0-9.9.9.9" newVersion="1.0.0.0" />

<codeBase version="1.0.0.0" href="file:///C:\PathToBizTalkDlls\Solution.Project.Module.dll" />

</dependentAssembly>

</assemblyBinding>

</runtime>

 

This approach can increase development speed and reduce the cost to maintain a BizTalk solution in a development environment. While this is not generally recommended for production environments, we do have clients that have a hard “no GAC” policy; yes, even in production. As such, those customers must have a mechanism for running a BizTalk solution sans GAC.