This post was originally published here.

Recently, I had a project where full side-by-side deployment was required.  In a first test phase of the automated deployment, we used MSBuild together with the Codeplex MSBuild Extension Pack. We tried deploying assemblies side-by-side, but BizTalk threw errors when trying to deploy a new version of our Blog.Codit.BizTalk.Pipelines assembly:

Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. SQL exception: “Violation of UNIQUE KEY constraint ‘UQ__bts_pipe__DD425CAE7908F585’. Cannot insert duplicate key in object ‘dbo.bts_pipeline’. The duplicate key value is (D6C53CD9-8466-4520-A85B-7BD887A57455).” 

I received this error when trying to deploy from Visual Studio, from MSBuild (using BTSTask.exe) and also when trying to deploy it manually via the Admin Console (Add Resource).  So the error is actually independent from the deployment source.  As BizTalk returned a SQL exception, I decided to run SQL Profiler and detected this call:

exec btm_CreatePipeline 
 @PipelineID='D6C53CD9-8466-4520-A85B-7BD887A57455',
 @Category=1,
 @Name=N'Blog.Codit.BizTalk.Pipelines.rcvSalesOrder',
 @FullyQualifiedName=N'Blog.Codit.BizTalk.Pipelines.rcvSalesOrder, Blog.Codit.BizTalk.Pipelines, Version=1.2.0.0, Culture=neutral, PublicKeyToken=xxx',
 @IsStreaming=0,
 @AssemblyID=265,
 @Release=2,
 @ID=@p8output

So the deployment logic tries to create a new entry in the bts_pipeline table, but it uses exactly the same (unique) ID of the pipeline of the older version.  This entry was already present in the bts_pipeline table:

D6C53CD9-8466-4520-A85B-7BD887A57455
Blog.Codit.BizTalk.Pipelines.rcvSalesOrder, Blog.Codit.BizTalk.Pipelines, Version=1.1.0.0.  

We opened a case at Microsoft Support for this issue.  They forwarded the issue to the BizTalk Product Team and we received this answer:

The pipeline guid is stored in the rcvSalesOrder.cs file.  The guid gets regenerated when eiter of the following occurs:

• The pipeline is saved from within Visual Studio
• The BizTalk project gets rebuild

As we executed a BUILD, instead of a REBUILD, a small change to our MSBuild script solved the issue:

<MSBuild Projects="@(ProjectsToBuild)" Targets="Rebuild" />

This behavior is rather inconsistent, because it only occurs when your assembly contains a pipeline object.

Big thanks to Microsoft for the fast and accurate support.