Party Settings being overwritten when deploying a specific Orchestration assembly

Topics: Bindings File, Settings Management and SSO
Mar 1, 2015 at 11:49 PM
Hello,

I am facing an issue when deploying a particular BizTalk project using BTDF, where the party settings get overwritten when they shouldn't be.

I've confirmed that the PortBindingsMaster.xml for this project does not have any party settings, like so:
 <PartyCollection />
In fact the issue occurs even when the BTDF proj file has the binding related flags switched off:
 <IncludeMessageBindings>false</IncludeMessageBindings>
 <UsingMasterBindings>false</UsingMasterBindings>
 <PortBindingsMaster>PortBindingsMaster.xml</PortBindingsMaster>
To isolate the issue, I switched off all components (IncludeSchemas, IncludeComponents, IncludeTransforms, etc.) and was able to repro the issue when IncludeOrchestrations was enabled:
 <IncludeOrchestrations>true</IncludeOrchestrations>
Further, the issue occurs with only one of the Orchestration projects added under ItemGroup\Orchestrations node.

The BTDF logs show the following trace entries for the orchestration assembly that is causing this issue:
    Information: Installed the "Communication.Orch.CommunicationDocument.dll" assembly into the Global Assembly Cache. (force=True)
    Information: Deploy operation succeeded.
    Information: Updating binding information.
    ConnectionString="Data Source=.;Initial Catalog=BizTalkMgmtDb;Integrated Security=True;Enlist=True;Application Name=Microsoft.BizTalk.ApplicationDeployment.Engine"
    Information: Updating send ports, send port groups, and receive ports...
    Information: Updating parties and enlistments...
    Information: Updating orchestration bindings...
    Information: Successfully updated binding information.
__ Information: Beginning post-update operations for assembly "Communication.Orch.CommunicationDocument, Version=1.0.0.0, Culture=neutral, PublicKeyToken=...".
    Information: Updating binding information.
    ConnectionString="Data Source=.;Initial Catalog=BizTalkMgmtDb;Integrated Security=True;Enlist=True;Application Name=Microsoft.BizTalk.ApplicationDeployment.Engine"
    Information: Updating send ports, send port groups, and receive ports...
    Information: Updating parties and enlistments...
    Information: Updated "Party: AC"
__ Information: Updated "Party: AD"
    Information: Updated "Party: CD"
    Information: Updated "Party: CU"
    Information: Updated "Party: DF"
    Information: Updated "Party: DO"
    Information: Updated "Parties and Partnerships"
    Information: Updating orchestration bindings...
...

This is different from the trace entries for other orchestration assemblies which shows that there is no binding information to restore in the post-update event:
    ConnectionString="Data Source=.;Initial Catalog=BizTalkMgmtDb;Integrated Security=True;Enlist=True;Application Name=Microsoft.BizTalk.ApplicationDeployment.Engine"
    Information: Updating send ports, send port groups, and receive ports...
    Information: Updating parties and enlistments...
    Information: Updating orchestration bindings...
    Information: Successfully updated binding information.
__ Information: Beginning post-update operations for assembly "Communication.Orch.MemberCommunication, Version=1.0.0.0, Culture=neutral, PublicKeyToken=...".
    Information: No binding information to restore. 
    Information: Ending post-update operations for assembly "Communication.Orch.MemberCommunication, Version=1.0.0.0, Culture=neutral, PublicKeyToken=...".
__

As a test, I even removed all artefacts in the orchestration project in question and the issue still occurs - so it appears this has nothing to do with the contents of the orchestration project.

What configuration controls the post-update event?

It appears some misconfiguration is causing this. Any pointers would be greatly appreciated!

Thanks and Regards,
Rohan.
Coordinator
Mar 2, 2015 at 4:30 AM
Hi Rohan,

Assuming that you took this from the Visual Studio Output window, I believe that the log output you pasted is coming from BTSTask.exe, not the Deployment Framework. If you look backwards (earlier) in the log file from that point, you should find the BTSTask.exe command line. I suggest that you dispense with testing your entire deployment and focus on that command line. Just run it directly from a Command Prompt as admin. You should see the same output.

It should be as simple as:
BTSTask.exe AddResource -Type:BizTalkAssembly -Source:"..\Project\bin\debug\Communication.Orch.CommunicationDocument.dll" -ApplicationName:"MyAppName" -Options:GacOnAdd,GacOnImport,GacOnInstall

I also have to ask -- you are not using the Deploy menu in Visual Studio, right? You should have the Deploy checkbox in Configuration Manager unchecked for all BizTalk projects. All bindings-related configuration should come long after the orchestration deployment during the ImportBindings step.

Thanks,
Tom
Mar 10, 2015 at 11:58 PM
Edited Mar 10, 2015 at 11:59 PM
Hi Tom,

Thank you for your reply!

I followed your suggestion and was able to repro the issue by testing with the BTSTask command. I've unchecked Deploy under Configuration Manager for all BizTalk projects and the issue still occurs. Yes, I was using the BTDF deploy menu in VS, but now that its occurring with BTSTask I suppose that rules out BTDF as the problem.

I don't see a reason why the bindings should be updated when executing the AddResource command in this case. It happens even if I remove all artefacts from the assembly in question - that is, strip it down to an empty assembly, or an assembly with just 1 schema for example.

So I tried changing the name of the assembly (from xxCommunicationDocument.dll to xxCommunicationDocuments.dll) & that caused the issue to go away. It looks like there is some stale reference associated with the assembly name that is causing an incorrect binding config to be applied.

Perhaps this is more apt for the BizTalk discussion forum - but if you have any inputs that will be highly appreciated!

Many thanks!

Regards,
Rohan.
Coordinator
Mar 11, 2015 at 5:22 AM
Hi, I'm glad to hear that you found a workaround -- and that I'm off the hook on this one. :-) Offhand, I can think of three questions:

1) Have you gone up to the <All Artifacts> node and checked that xxCommunicationDocument.dll doesn't exist anywhere else, like in the default BizTalk application?
2) Have you done a version upgrade of BizTalk in this environment, or was it a clean install? If an upgrade, maybe something didn't upgrade cleanly. There are many documented upgrade issues.
3) Have you tried undeploying xxCommunicationDocument.dll then searching the management database for references to it or those parties?

Thanks,
Tom