Preserving BizTalk deployment settings in TFS Source Control

When we configure Deployment Settings in Visual Studio projects, our database settings (“Configuration Database” and “Server”) and BizTalk Settings (“Application Name”) are only stored in a personal “*.btproj.user” file. By default these files are ignored in your check-ins, but that may not be the desired effect. We recommend that those settings are also stored in your source control (forever) to preserve testing configurations and help you and other team members pick your archived project easily.

In one of my previous post, “Failed to add resource(s). Resource (…) is already in the store and is either associated with another application or with another type”, I explained a common deployment problem that can happen when we work with BizTalk Server project and Team Foundation Server. In this post I will try to explain how can we avoid this problem and how can we store deployment settings in TFS so that can be shared by our team members.

sharing team members

Firstly, is important for you to know that Visual Studio, I believe since BizTalk 2009 onwards, stores the deployment setting of BizTalk projects in the  Visual Studio Project User Options file: “*.btproj.user”. This is an XML file that contains not only the BizTalk deployment Settings but also several personal user settings like References path, test file names and so on.

Regarding BizTalk deployment properties, all this setting are stored in the “*.btproj.user” file:

  • Application Name (ApplicationName): Is the name of the BizTalk application that we want to deploy the assemblies in this project. If the application already exists, the assemblies will be added to it when you deploy the project. If the application does not exist, the application will be created. If this field is blank, the assemblies will be deployed to the default BizTalk application in the current group (“BizTalk Application 1”). Names that include spaces must be enclosed in double quotation marks (“).
  • Configuration Database (ConfigurationDatabase): Is the name of the BizTalk Management database for the group, the default value is “BizTalkMgmtDb”.
  • Server (Server): Is the name of the SQL Server instance that hosts the BizTalk Management database on the local computer. By default, this is usually the name of the local computer.
  • Redeploy (Redeploy): Boolean property that indicates if you want to allow redeployments from within Visual Studio. Setting this to “True” (the default) enables you to redeploy the BizTalk assemblies without changing the version number.
  • Install to Global Assembly Cache (Register): Setting this to “True” (the default) installs the assemblies to the Global Assembly Cache (GAC) on the local computer when you install the application. Set this to False only if you plan to use other tools for this installation, such as gacutil.
  • Restart Host Instances (RestartHostInstance): Setting this to “True” automatically restart all host instances running on the local computer when the assembly is redeployed. If set to False (the default), you must manually restart the host instances when you redeploy an assembly.

Let’s see an example of this file:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
    <Server>BTS2013LAB01</Server>
    <ConfigurationDatabase>BizTalkMgmtDb</ConfigurationDatabase>
    <ApplicationName>MyTestApplication</ApplicationName>
    <Redeploy>True</Redeploy>
    <Register>True</Register>
    <RestartHostInstances>False</RestartHostInstances>
  </PropertyGroup>
  <ProjectExtensions>
    <VisualStudio>
      <FlavorProperties GUID="{EF7E3281-CD33-11D4-8326-00C04FA0CE8D}">
        <Files>
 <File Path="NormalizeAndRemoveUnnecessaryData\Client.xsd">
 <ValidateTestMapInput>True</ValidateTestMapInput>
 <ValidateTestMapOutput>True</ValidateTestMapOutput>
 <TestMapInputInstanceFilename></TestMapInputInstanceFilename>
 <TestMapOutputInstanceFilename></TestMapOutputInstanceFilename>
 <TestMapSourceType>0</TestMapSourceType>
 <TestMapTargetType>0</TestMapTargetType>
 <EditorOutputInstanceFilename></EditorOutputInstanceFilename>
 <EditorInputInstanceFilename></EditorInputInstanceFilename>
 <GenerateInstanceOutputType>0</GenerateInstanceOutputType>
 <ValidateInstanceInputType>0</ValidateInstanceInputType>
 <PropertySchemaFileName>PropertySchema.xsd</PropertySchemaFileName>
 <AutoRefreshSchema>0</AutoRefreshSchema>
 </File>
 </Files>
      </FlavorProperties>
    </VisualStudio>
  </ProjectExtensions>
</Project>

Secondly, you must keep in mind that these file (“*.btproj.user”) are typically not under source control. The reason is that the Visual Studio deployment feature main focus is for development scenarios where one user settings might differ from another. And it will be up to you, or your client, to decide if you want these files to be checked in and available to all of the developers on your team.

However, when the team shares the same BizTalk developer environment, is expected that all build-related information required at the time of build can be shared between developers in an easy way… unfortunately, there is no easy way and one of the possible solutions is to force storing “*.btproj.user” files in the source control so that this setting can be shared by all the team members.

Although I know that the “*.btproj.user” Files are not supposed to be shared because they contain personal settings (as explained before) sometimes this approach can be considered a good practice.

Of course that this “workaround” can lead to additional problems, simply because these files contain some user settings, that can be different than yours (for example schema file properties only allows a valid full path file names) that can change your setting and probably don’t work in your developer station and need to be reconfigured, but this can be minimized with some precautions and good practices.

How can we check if “*.btproj.user” Files are stored in TFS and how to add them?

  • Open Visual Studio 2010 and select the “View” menu and choose “Team Explorer” to connect to your TFS
  • Access to “Source Control” and from the source control tree, you must browse to the project that you want.
BizTalk Project Source Control Explorer
  • Right-click on the project folder and select “Add Items to Folder…” option
BizTalk Project Add Items to folder
  • Select the BizTalk project folders present in the solution, and click “Next”
BizTalk Project Add Items to Source Control
  • From this window, we can see that the “*.btproj.user” files are not included in the source code
BizTalk Project Add Items to Source-Control Items to add
  • To add them, you just need to select them and then click “Finish”.

Testing this workaround

After applying this workaround, when I try to access and get the last version of the project with a different user, all the settings were correctly properly fulfilled:

BizTalk deployment setting fulfilled

And after a battery of tests that I performed very quickly with a member of my team, here are some suggestions to avoid some problems that sometimes happens and we face in our tests:

  1. Make a Label in the “*.btproj.user” file to properly and easily identify a clean BizTalk Application Deployment Settings with all important deployment settings and without any personal settings. This way you can, at any time, force to get that specific version of the file
New Label
  1. If you already have a local version of the project in your environment, you should get the last version and force to overwrite all the files by:
    1. Access to source code, in the project folder, right-click and choose the option “Get Specific Version…”
    2. Check all the option in the Get Windows:
      1. Project folder
      2. “Overwrite writable files that are not checked out” option
      3. “Overwrite all files even if the local version matches the specified version” option
      4. Choose the type “Latest Version” and click “Get”
BizTalk Project Source Control Explorer get Specific version

In addition, once you have the correct settings, even if each individual users change locally their personal settings they are not committed to the source control by default, which means that it will not spoil the settings of other users every time someone does a check-in. Again if you want to change this setting in the source control you need to force this to happen.

Final notes

Probably this is not the best approach for sharing the BizTalk Application Deployment Settings across all the team but is a valid way and much better than each member manually adding to their solution. I will try to find a better way and if you already have it, feel free to comment and share it here.

References:

Once again I want to thank José António Silva, my ALM guru for the help! And thank Bruno Zacarias for helping me testing this workaround.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.

2 thoughts on “Preserving BizTalk deployment settings in TFS Source Control”

Leave a Reply

Your email address will not be published. Required fields are marked *

turbo360

Back to Top