BizTalk Server 2020 CU1

ParikshitGupta

If you try and overwrite any BizTalk assembly artefact with the same assembly version number that has a reference to it, you will be blocked by the Administration console.   This happens both at the code level, and at the configuration level.

Configuration Level

If you create a project with a Pipeline and deploy that into Application1, and then reference that from Application2 and utilise the pipeline in a Receive Location/Send Port in Application2, you will be blocked from updating the assembly in Application1.  Even if you, as the administrator, know that there are no (or no breaking) changes to the assembly being updated.

This happens due to a constraint in the database, e.g pipelines are a good example, but not the only cause:

The DELETE statement conflicted with the REFERENCE constraint "bts_sendport_foreign_sendpipelineid". The conflict occurred in database "BizTalkMgmtDb", table "dbo.bts_sendport", column 'nSendPipelineID'.

This will happen if you deploy via Visual Studio, btstask, or import via an MSI.  The only way to handle this currently is to remove the reference from other applications, either by changing the bindings, or removing the application completely.  Whilst this sort-of makes sense when the application is enlisted, it feels unnecessary when unenlisted (and given that assemblies are loaded into an AppDomain, I'm not sure being able to do with when things are enlisted should be blocked either).

Desired behaviour here (for me) would be to have the import process handle the swapping out of components and only present a fatal error and rollback if that configuration would not be applicable after the import is completed, or that a currently active/started component is referencing it.

Development/assembly level

The issue also presents itself with compile-time references between BizTalk assemblies.

If you have a schema in a resource in Application1, and then reference that from another project/assembly (e.g. as you might do with a common schema and map to something more specific elsewhere), then you can no longer deploy Application1 without first completely removing any referencing applications completely from BizTalk (or, deploying all assemblies in the same transaction, which is not easily done if you are talking about multiple applications).

e.g.

Cannot update assembly "BtsDependency1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9143bb74dd62198d" because it is used by assemblies which are not in the set of assemblies to update.
To update the assembly, remove the following assemblies:
BtsDependency2, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9143bb74dd62198d (mscorlib)

The desired behaviour here is to only present a fatal error if the assembly is being removed and not overwritten.

I'm not sure the purpose of the existing constraint, as it does not protect against changes in the base assembly breaking any referring assemblies; all it does is add an irritating step which requires shutting down of applications to drop in patches to BizTalk artefacts.

Note on versioned DLLs

In my experience, it's fairly common to stick with a single assembly version for BizTalk assemblies.  I appreciate that it is possible to workaround some of the above slightly by having different version numbers and running concurrent versions, this introduces another world of pain, not just in managing binding files, but also in managing class references inside referring applications.  Multiple versions of a messagetype can also cause runtime errors.

e.g. If you use Advanced Functoids to reference other assemblies these need to be manually updated to pick up new versions.  If you use custom XSLT functions, these need to have the XML files manually updated.  None of these steps are build-server/CI friendly making the process of building a new version unfavourable.

Loose coupling

Given that BTS is frequently used to loosely couple services, these constraints are very tight.  Being able to late-bind/loosely couple within BizTalk itself is sorely needed.

Thanks,

Alastair