BizTalk Versioning Strategy (3/4)

Continued from part 2.

.NET Versioning.

So every problem seems due to the fact that orchestration are tightly coupled with .NET types representing message schemas and therefore they’ll fail to execute if fed with wrong .NET Type.

In fact we’ve reduced BizTalk Versioning strategy problem to a normal .NET Versioning one:

• We’ve deployed an application (our orchestration) referencing types contained in another assembly (our schemas, v1.0.0.0).
• We’ve deployed a new version of this referenced assembly (v1.0.0.1).
• Will our application continue to work unaffected when receiving 1.0.0.1 types instead of 1.0.0.0?

The .NET answer is “it depends”.

In fact, as depicted here,

The specific version of an assembly and the versions of dependent assemblies are recorded in the assembly's manifest. The default version policy for the runtime is that applications run only with the versions they were built and tested with

So the answer seems to be a sounding no but, continuing to read:

unless overridden by explicit version policy in configuration files (the application configuration file, the publisher policy file, and the computer's administrator configuration file).

So there’s a way: by default the orchestration will crash (because receiving unexpected type) but we can override this behavior simply by declaring explicitly the version policy!

The above page suggested 3 approaches, let’s examine them in details:

Application Configuration File

This approach consists in putting redirection directives directly inside the application configuration  file.

This means that we should place our redirection from 1.0.0.0 to 1.0.0.1 directly inside the BTSNTSvc.exe.config file.

I don’t like to mess with BizTalk application config file and it’s wrong even from a logical point of view: this kind of redirection is thought for application developers (that in this case is the BizTalk product group) to explicitly affirm (in the application config) that the program will work with these assembly version redirections. But I’ve not developed BizTalk Server, I’ve simply developed some components hosted in BizTalk Server.

So I don’t like this approach too much.

Computer Administrator Configuration File

This approach consists in putting redirection directives inside the machine configuration  file.

If possible I like this approach less than the previous one for the very same reasons:

If I don’t like to mess with BizTalk Configuration File you can imagine how much I hate to mess with the whole Machine.config.

And, from a logic point of view, this kind of redirection is thought for system administrators of the machine and I’m not either too, I’m just a developer who has components hosted on that machine.

Publisher Policy File

This approach, a bit more complex than the previous two, consists in generating a twin policy assembly file which, when deployed together with the original assembly, enable redirection.

This is the best approach for a biztalk developer: it is used by a component developer (and we’re component developers) to state that a component is compatible with another version of the same (and this is exactly what we’re trying to do).

Understanding how to generate a Publisher Policy File is off topic for this (too long) post, but I placed on MSDN Code Gallery a powershell script that should help you producing your publisher policy files.

Recap

My policy for schema versioning is therefore the following:

Each time I made a (backward compatible) change in a schema (such as adding a field to an existing schema or adding a new schema to the assembly) I simply increase build or release number.

My build process will build the newly changed schema artifacts producing also the publisher policy file (using a slightly modified version of the script I linked above).

Then, on the BizTalk box, I’ll deploy the new version of the schemas (no need to unenlist orchestration or remove artifacts because I’m simply adding a new side by side schema).

Afterwards I put in gac the publisher policy file corresponding to the new schemas.

We had a zero downtime (we just deployer new artifacts, neither stopped nor removed old ones) and the net effect is that now every biztalk artifact (orchestration, maps, pipelines, etc) will use the newest (and backward compatible) artifact without problems.