Assembly binding redirect in BizTalk

Scenario/Challenge

As BizTalk middleware integration system, we integrate many systems and should be capable of handling the changes within without bring down the system. 

Small changes like service WSDL or canonical schema update cause full deployment and with each new enabler, multiple full deployments would be hard to manage. Amount of time spent in doing development and complete round trip testing would be huge. Additionally, team should prepare instruction document to handover to SCM. 

Solution 
As BizTalk architecture is based on publish-subscribe model, just versioning assemblies’ wouldn’t help much to overcome this problem.
As message would be defined by MessageType this should be changed along with assembly version. If you need to support long-running orchestrations, side-by-side deployments, or no-downtime upgrades, then you should implement an assembly versioning and packaging strategy.

In order to perform assembly versioning of BizTalk artifacts, your BizTalk solution assemblies need to be factored (packaged) in such a way to allow for BizTalk Server versioning. 

There are 4 types of factoring: 

• No factoring:- All BizTalk artifacts are in one assembly. This is the easiest to understand and deploy, but provides the least amount of flexibility. 

• Full factoring:- Each BizTalk artifact is in its own assembly. This provides the most flexibility, but is the most complex to deploy and understand.

• Optimal factoring:- Somewhere in-between “no factoring” and “full factoring” based on in-depth analysis of your BizTalk applications. In addition to versioning, this allows you to easily implement your BizTalk Host design. This is achieved by looking for relationships among BizTalk artifacts. Artifacts that are always version-ed together can typically be put in the same assembly. If independent versioning of the artifacts is required, then they must be put in different assemblies. This is the level of factoring you want to achieve. 

• Assembly binding re-directs:-If there are changes in common artifacts like call orchestrations and common schema increment the version for these artifacts and deploy it to admin console. Assemblies referring to old version of common artifacts and in order to make them use of the latest artifacts in from assembly we should make an entry in btsconfig file (available in installation path; i.e C:\Program Files (x86)\Microsoft BizTalk Server 2013) for the updated common artifacts as shown below, thus whenever old assembly is loaded binding redirect will happen and latest assembly would be used for process.