Deploying a BizTalk solution from Visual studio is a piece of cake! It is interesting which procedures Visual Studio handles between BizTalk. Especially for troubleshooting!
A default BizTalk project contains several deployment options. By navigating to the properties of the project, in the tab “Deployment”, we can change the deployment behavior of Visual Studio.
One of the most interesting and time saver options is the property “Redeploy”. This option is by default on True while creating a new BizTalk project.
In the process of deploying a BizTalk assembly, you first needed to manually stop, unenlist, and unbind artifacts contained in the assembly in BizTalk Server and then remove the assembly from the BizTalk Management (configuration) database before deployment.
Visual Studio will handle all those steps for you with this option Redeploy.
The behavior of a redeployment procedure is significant different than a normal deployment. MSDN offers a small introduction how to work with redeployment from Visual Studio: http://msdn.microsoft.com/en-us/library/aa560363.aspx.
Each time when Visual Studio tries to deploy a solution to BizTalk, the log of the deployment is saved to a specific file. In some cases this might be interested to read this file again.
The deployment logs can be found in
This folder contains xml files. It is possible to rename a file to an .html extension, so this can be viewed in a browser of your choose.
Since it is necessary to unbind artifacts while redeploying, Visual Studio will first backup the binding files of the existing application before each redeployment. After this backup, all artifacts change to a stopped state, unenlisted and eventually in an unbinded state. If artifacts are referring to other artifacts, they will be removed. After the removal, resources will be deployed. A backup of the binding file will be applied, so the state of unbinded artifacts, will automatically change as it was before the deployment.
The deployment binding files can be found in
If something goes wrong during the redeployment, keep in mind that BizTalk can stop between the deployment procedure, where the problem occurs. In practice, this can result to an application where only a half of the resources have been deployed.
I lately came across such a problem: When editing a currently started orchestration (A), that calls a new orchestration (B), the redeployment will fail. This error message will be displayed:
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=22.214.171.124, Culture=neutral, PublicKeyToken=f96e91b6b75bb727'. Could not enlist orchestration 'Orchestration.UpdateRequestStatus'. All orchestration ports must be bound and the host must be set.
This is simply because the backup of the binding files applies that the orchestration should be in an active state, however the host instance is not yet set for orchestration B. This will result in an error.
A solution to this problem is, to disable orchestration A, redeploy the application. Configure the host instance from orchestration B and eventually start orchestration A.
Keep in mind that it is sometimes required to remove the backup of those binding files and redeploy again, especially when the redeployment fails.
To save time during the deployment, keep the redeployment option to ON for each project. Unless you are not satisfied with this behavior.
For troubleshooting reasons, it is possible to view the deployment result logs from Visual Studio.
When using the redeployment option, the current binding settings should be compatible with the new resources in BizTalk.