Both I and others have been experiencing an issue in BizTalk 2006 beta 2 (and previous versions) whereby if you attempt to deploy a BizTalk assembly in Visual Studio that references another BizTalk assembly that is also being referenced from another BizTalk assembly you can end up in a situation where the other referencing assembly is un-deployed.
Figure 1 – Deployment Options in Visual Studio
Did that make sense? Well let’s explain that in a little more detail.
Let’s say you have BizTalk Project 1, BizTalk Project 2 and BizTalk Project 3. BP1 and BP2 both reference BP3 like so:
Figure 2 – Project References
Now, if you wish to redeploy BP1 from within Visual Studio you will end up with BP1 and BP3 deployed, but BP2 removed. Why?
Well, when deploying BP1 any referenced assemblies will also be redeployed as part of its redeployment. This redeployment is simply to remove the assembly and install the one in your project. So, BP1 will initially remove and install BP3.
Now, the complexity comes from the fact that BP3 is referenced by BP2 in our example, so this also has to be redeployed. However, as BP2 is not related to our deployment of BP1 i.e. there are no references; it cannot be installed, simply removed.
Therefore, BP2 is removed, BP3 is removed and then installed and BP1 is removed and installed. This leaves us with only BP1 and BP3 remaining.
Obviously this is a simple annoyance within the deployment process in Visual Studio and if you know what happens under the covers then you can cater for it, or simply use another mechanism to deploy in your development environment such as from within BizTalk Administrator. I do believe that there should be a warning included in the Visual Studio Error List window to inform you what has occurred however.
A bug that I believe I have come across that is related to this issue is that when you do perform a deployment scenario as described above, you could be left with some referential integrity issues in BizTalk Administrator.
Figure 3 – BizTalk Administrator Resources
In Figure 3 you can see that the three assemblies appear to be deployed, even though I have just said that BP2 is removed. That is the issue, it really isn’t deployed and if you attempt to remove it you will receive an error like the following:
Figure 4 – Remove Error
I have obviously raised this with Microsoft, so hopefully this inconsistency in BizTalk Administrator will be fixed. However, I am not sure how they are going to approach the underlying problem. Whether they will provide an option to deploy in a different way, report on what occurs therefore raising awareness, or simply update the documentation.
A point to note that I have not mentioned before, you cannot simply redeploy BP2 again, as it would then cause the same process to happen, but this time in reverse. So you would end up with BP2 and BP3 deployed, but this time BP1 would be missing.
Happy BizTalking!