Random Encounters during BizTalk Deployment

To be honest, deployment and version management are topics that I understand in theory but do not practice often.  Fortunately this week I picked up a deployment issue and went through a refresher course.  Just thought I would share a few observations that resurfaced after being lost in dormant brain cells. 

I started off with two simple BizTalk projects.  Project A contained my schemas and maps.  Project B referenced Project A and contained an orchestration that used the schemas and maps in Project A.  I deployed both assemblies and bound the orchestration to a file receive port and file send port.  Message flow worked fine without error at this point.

I then decided to make some modification to a schema.  Minor change only and the project built without error.  I did a full stop of the BizTalk application before deploying the updated schema assembly.  Deployment was successful.  I restarted the BizTalk host instance in addition to my BizTalk application to be certain the updated schema assembly was loaded.  All looking good so far, right?  So I dropped a test document into the file receive location again but this time no output file got created.    A bit surprised so I looked at the application event log for some clue. Didn’t expect to see a routing failure being reported.  I didn’t change the binding information of the orchestration and my BizTalk application started without error so I assumed that the orchestration was enlisted and running.  A refresh of the application in BizTalk Administration Console revealed the problem.  The orchestration was no longer deployed and therefore there was no subscriber to the message.  What happened here was that because the orchestration assembly depended on the schema assembly, the re-deployment of the schema assembly caused both assemblies to be un-deployed first.  After that, the schema assembly was re-deployed but not the orchestration assembly.  Everything worked fine again once I re-deployed the orchestration assembly.  I remember now writing documentation for this behavior awhile back.  Not a big deal but good to keep in mind when you deploy/un-deploy assemblies with dependencies. 

Interestingly, the above behavior did not happen if you update (overwrite) an assembly as resource from BizTalk Administration Console.  Just don’t delete the schema assembly first.  That’ll cause both assemblies to be removed.

Lastly, I decided to up the assembly version of my schema assembly and deployed the new version.  Now I have 2 versions of my schema assembly in side by side deployment.  Again, no error with deployment.  Restarted my BizTalk application and host instance.  Again, the test message failed.  This time the failure was in XLANG.  The orchestration received “unexpected message type”.  When the message was published, it was resolved to the latest deployed schema assembly, but because I added the updated assembly this time with BizTalk Administration Console, the orchestration was not updated.  It was still expecting earlier version of the message.  A quick rebuild and redeploy of the orchestration assembly resolved the issue. 

The observations above are all very straightforward.  Just little things to keep in the back of the mind.   More to come as I dig deeper into lost memory.