BizTalk Deployment Gotcha

Over the past month or so I’ve been putting together some fairly extensive BizTalk training for customers and have just finished 3 deliveries so I’m trying to catch up!

During this training I ran some labs, which seemed to went well but I came across some BizTalk deployment behaviour that had completely passed me by, mainly due to the un-deployment habit I’d got myself into.

So, if you want to update your Orchestration with a new version, you Unenlist and/or Stop, this removes any Subscription records in the Message Box, and stops any Orchestrations from executing, during this process you get a dialog box that prompts you to Terminate Orchestration Instances, Stop Hosts, etc.

I (for some reason) have always checked all of the options, but (and quite rightly so) people on the course weren’t doing this and were seeing that a newly deployed Orchestration wasn’t running correctly – a bit of head scratching and we worked out that BizTalk was still using the old Orchestration by looking at the Orchestration Debugger (it was missing out shapes that had been added).

BizTalk caches Assemblies in memory as you’d expect for performance reasons and this isn’t updated unless you change the version of the assembly or recycle the BizTalk host. In our scenario the version number wasn’t changed hence BizTalk didn’t pick up the change.

I’ve never seen this, because I’ve got into this habit of Terminating the BizTalk host which of course flushes the assembly cache. This isn’t a BTS problem, but usual .NET behaviour instead.

So – change those Assembly versions or terminate the host! J

Comments

• Anonymous
  July 04, 2004
  The comment has been removed