Visual Studio stores binding files for BizTalk Server project assemblies. Those files are used when BizTalk application is redeployed using VS. This way you may remove, i.e. orchestration assembly from BizTalk application resources and still have your orchestrations fully bound when you deploy the assembly again.
But sometimes the binding file that VS stores may get out of sync with your current solution and then you won’t be able to deploy the solution on your development machine anymore. Errors may be various, including:
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 ‘[…]Orchestrations.CreateConstructor,[…]Orchestrations, Version=188.8.131.52, Culture=neutral, PublicKeyToken=[…]’. Could not enlist orchestration ‘[…]Orchestrations.CreateConstructor’. All orchestration ports must be bound and the host must be set.
Solving the issue requires removing invalid assembly binding from C:\Users\[user]\AppData\Roaming\Microsoft\BizTalk Server\Deployment\BindingFiles folder.
BizTalk Server 2013 (CU2) could not download a file from a SharePoint 2013 document library. File was left in checked out state on SharePoint and on BizTalk Server you could read:
The Windows SharePoint Services receive adapter has failed to process the SharePoint file test.txt. The following error has been encountered:
[System.InvalidCastException] Unable to cast object of type ‘System.Collections.Generic.Dictionary`2[System.String,System.Object]’ to type ‘Microsoft.SharePoint.Client.Field’.
Error code: 12310
Once you have addressed the issue causing this problem, you can undo the check-out for this file and the adapter will try to process it again. Continue reading
Not every error in BizTalk is what it pretends to be. Error in the data can break FTP connection while file is being sent. Recipient thinks he got the file, but half of it is missing. I learned it lately.
In BizTalk there is a flow routing data from FILE receive location to FTP send port. File is received in XML format and sent as a flat file using flat file assembler in the send pipeline. One cold winter morning BizTalk started suspending messages on the send port with the following error:
The data send failed unexpectedly. Inner Exception details: “(null)”. Continue reading
Update: this issue was addressed by Cumulative Update 6 for BizTalk Server 2010
Recently I was investigating an interesting problem in BizTalk Server 2010. All of the sudden events generated for receive locations just stopped being recorded. Noone has changed the configuration. For a simple messaging scenario, in which message flows from receive location A to a send port B, you could see the send port events being tracked. But no sign of when and where the message was received.
BizTalk Orchestration Debugger does not allow for copy-pasting the tracked events table. But with access to BizTalk tracking database you can export the data easily with only one SQL script. Then you can copy and paste it to Excel. Continue reading
Version: Microsoft BizTalk Server 2010 Enterprise Edition 3.9.469.0
[Dynamic send ports use default send handlers defined for adapter.]
Application with a dynamic send port was imported and started. We’ve found out later that we need to have the dynamic send port running on a different server. So we’ve added a new (default) send handler with a different host, removed the previous send handler and restarted all host instances. But BizTalk was still running the dynamic send on old server and each time failing with “Routing failure” error. Continue reading