Follow Up: Business Process Versioning - Manually GAC new Version

In my post on versioning business processes I deliberately avoided to comment on a technique for versioning that are sometimes discussed. I'm talking about updating the orchestration by GACing a new version manually, i.e. not using BizTalk's deployment features. This is a dangerous technique which risks corrupting your running orchestration instances, I would not recommend using this on a production system unless you are fully aware of the risks involved.

Why am I writing about this if I don't like it. The answer is that during the development phase this can be a useful technique to quickly "deploy" a fix that you need to validate. Doing the full cycle of terminate instances, undeploy orch, deploy orch and resubmit test messages may take too long (if you do it lots of time).

For those of you who don't know what I'm talking about, let me explain. During deployment of an assembly to BizTalk one of the steps is to register the assembly in the Global Assembly Cache (GAC), other steps include registering all artifacts in the BizTalk repository. When BizTalk during run-time needs to create an instance of an orchestration is loads the assembly from the GAC.

This means that if you replace the assembly in the GAC you will actually short-cut the BizTalk deployment process and can force BizTalk to use a new version of an assembly without the normal controls that BizTalk performs during deployment. To GAC the orchestration assembly you can use GACUTIL.EXE, there is no need to use any BizTalk tool.

So, if it is this simple to deploy new versions of an orchestration why shouldn't you use it all the time? The problem is that by taking a short-cut you avoid the checks that the BizTalk developers has put there for a reason. I'm sure there are several good reasons for using the normal deployment model, but the one I'm most concerned with is the layout of serialized state.

When you have existing instances of long-running orchestrations you can be quite sure that at least some of them have been dehydrated to persisted their state in the database, e.g. while waiting for an event which will activate them again or due to restart of the host. When an orchestration instance is persisted all state is serialized based on how the orchestration was designed, which scopes were used, variables, etc. (the exact format is unknown to me). When BizTalk rehydrates the instance and continue running the business process it creates an instance of the orchestration and fill it with the state information from the database.

Now consider a case where you have replaced the orchestration assembly in the GAC when the orchestration instance is restarted. What if the serialization format between the saved state and the format expected by the new assembly doesn't match? Probably you will get a nasty error in the Event Log and the orchestration instance will be terminated.

So, the risk you take when overwriting the orchestration in the GAC with a new version is that you will corrupt any existing instances. Of course, with minimal changes (whatever that means) and careful testing you might be able to use this technique a few times to make emergency fixes in a production environment, but you never know when your tests will prove insufficient...

Probably someone "out there" has done empirical tests to examine what affects the persisted/serialized state. If I find such information I will post a link here.