BizTalk 2006 seems to have a deployment quirk that has been no small source of frustration for me. I don't know if this is widespread or if I just have a bad install but it seems that whenever I change a port (add a port or remove a port) I get an error similar to the following when I try to deploy that assembly from Visual Studio,
Error 26 Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. Failed to update binding information. Could not enlist orchestration 'Orchestration.UpdateRequestStatus,Orchestration, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f96e91b6b75bb727'. Could not enlist orchestration 'Orchestration.UpdateRequestStatus'. All orchestration ports must be bound and the host must be set.
I've done some reading and a lot of thinking and all I can come up with is that BizTalk must be cacheing the binding information and reapplying it when I redeploy the assemblies. The part of it that burns me is that the DEPLOYMENT of the orchestrations fails because of a binding error. If you think about that for a second you realise that you can not change the binding information for assemblies that are not deployed so you get stuck.
I have not been able to find references to the binding cache, though my research is admittedly limited. On the hunch that this cache exists and is the source of my problem I tried incrementing the version on my orchestration assembly so BizTalk would ignore its previously cached info (its a new assembly version after all) and voila! It deployed my assemblies without complaining.
Two possible solutions to this that i know of are:
- Change version (or key I suppose) on the orchestration assemblies
- Deploy the orchestration assembly by adding it as a resource to the appropriate app in the biztalk admin tool