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 also be 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 posts, 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 a BizTalk Server project and Team Foundation Server. In this post, I will try to explain how we can avoid this problem and how we can store deployment settings in TFS so that they can be shared by our team members.
Firstly, it is important for you to know that Visual Studio, I believe, since BizTalk 2009 onwards, stores the deployment settings 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 the references path, test file names, and so on.
📝 One-Minute Brief
BizTalk project deployment settings (like Application Name and SQL Server) are stored in local *.btproj.user files, which are excluded from source control by default. This causes deployment issues for other team members. This post explains a workaround: manually adding these files to TFS to share consistent build configurations across the development team, along with best practices to manage personal settings using labels.
Regarding BizTalk deployment properties, all these settings 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 restarts 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 files (*.btproj.user) are typically not under source control. The reason is that the Visual Studio deployment feature’s main focus is for development scenarios where one user’s settings might differ from another’s. 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, it 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, 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 on the project folder and select the Add Items to Folder… option.
- Select the BizTalk project folders present in the solution, and click Next.
- From this window, we can see that the *.btproj.user files are not included in the source code.
- 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 are correctly 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 happen and we face in our tests:
- 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 yourself to get that specific version of the file.
- If you already have a local version of the project in your environment, you should get the latest version and force to overwrite all the files by:
- Access to source code, in the project folder, right-click and choose the option Get Specific Version…
- Check all the options in the Get window:
- Project folder.
- Make sure the option Overwrite writable files that are not checked out is checked.
- Make sure the option Overwrite all files even if the local version matches the specified version” is checked.
- Choose the type Latest Version and click Get.
In addition, once you have the correct settings, even if each individual user changes their personal settings locally, 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 the entire team, but it 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.
Once again, I want to thank José António Silva, my ALM guru, for the help! And thank Bruno Zacarias for helping me test this workaround.
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
This is a solution to a problem you would not have if you would make use of the Deployment Framework.
Unfortunately, many of us don’t like the way the deployment framework partitions the projects in a solution.