Preserving BizTalk deployment settings in TFS Source Control

Posted: February 12, 2014 in BizTalk
Tags: , , , , ,

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 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.


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 Project user option file: “*.btproj.user” file. This is a 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 to 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 by 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="">
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
      <FlavorProperties GUID="{EF7E3281-CD33-11D4-8326-00C04FA0CE8D}">
		<File Path="NormalizeAndRemoveUnnecessaryData\Client.xsd">

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, simple because this files contains some user settings, that can be different that 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.


  • Right click in the project folder and select “Add Items to Folder…” option


  • Select the BizTalk project folders present in the solution, and click “Next”


  • From this windows we can see that the “*.btproj.user” files are not include in the source code


  • To add them, you just need to select them and then click “Finish”.
Testing this workaround

After applying this wokaround, when I try to access and get the last version of the project with a different user, all the settings where correctly properly 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


  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 writeable 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”


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 add 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.


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

  1. Anonymous says:

    This is a solution to a problem you would not have if you would make use of the Deployment Framework.

  2. Anonymous says:

    Unfortunately, many of us don’t like the way the deployment framework partitions the projects in a solution.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s