BizTalk Server Best practices, Tips, and Tricks: #9 Visual Studio BizTalk Server Deployment properties

Published on : Jan 31, 2023

Sandro

Author

Welcome again to another BizTalk Server Best practices, Tips, and Tricks blog post! In my previous blog posts, I discussed some essential tips and tricks for BizTalk Server administrators:

And for BizTalk Server Developers:

Today I’m going to speak about another critical Best practice, Tips and Tricks for BizTalk Server developers: How to easily configure Visual Studio BizTalk Server Deployment properties.

Visual Studio Deployment in BizTalk

Visual Studio BizTalk Server Deployment properties

It’s nothing new – especially for BizTalk developers with experience – that before you can deploy a solution from Visual Studio into a BizTalk application, you must first set project properties. Otherwise, two things may happen:

The deployment will fail when you try to deploy it through Microsoft Visual Studio.
The assemblies, and all their artifacts, will be deployed to an unwanted BizTalk Application (typically BizTalk Application 1)

So, if that is so basic, why I’m addressing this?

Indeed it is one of the BizTalk developer’s most basic tasks if you want to deploy the solution from Visual Studio – and this happens almost every time we are doing a solution or changing a solution in the development environment. But you need to be aware, and this is important: If a solution in Visual Studio contains multiple projects, you must separately configure the properties for each project.

To configure project properties, you normally need to:

In Visual Studio Solution Explorer, right-click a project for which you want to configure properties, and then click Properties.
Click the Deployment tab in the Project Designer.
Configure the following project properties
- Application Name: Name of the BizTalk application to which 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. Names that include spaces must be enclosed in double quotation marks (“).
- Configuration Database: Name of the BizTalk Management database for the group, BizTalkMgmtDb by default.
- Server: Name of the SQL Server instance that hosts the BizTalk Management database on the local computer. In a single-computer installation, this is usually the local computer’s name.
- Redeploy: Setting this to True (the default) enables you to redeploy the BizTalk assemblies without changing the version number.
- Install to Global Assembly Cache: 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: 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 redeploying an assembly.
- Enable Unit Testing: Specifies whether to enable unit testing for the project.
And then click OK.
Repeat the first three steps for each project in the solution.

Visual Studio BizTalk Server Deployment properties

But you may encounter two main issues or problems with this:

By default, you need to do these operations manually for each project.
- Despite seeming an easy task, now imagine doing that if you have almost 200 projects inside a unique Visual Studio Solution! It will be an insane and time-consuming operation.
If it is not that critical when you are creating a brand new project, but the main problem happens when:
- We are migrating from on old BizTalk Server version to a newer version.
- Or when a new user downloads the source code from TFS or DevOps, and in that case, they need to configure some of these properties before they can deploy the solution to our BizTalk Server environment.

So, is there a better and fast way?

Yes, there is, and that is why I like PowerShell! We can easily script these tasks with a simple PowerShell script and reuse it for all projects.

For example, with this PowerShell: Fixing BizTalk Project Deployment Properties with PowerShell, you can parameterize all projects inside a Visual Studio Solution running a single line of code and avoid spending numerous hours doing this task manually.

$allPropertyGroup = $xml.Project.PropertyGroup
foreach($node in $allPropertyGroup)
{
    if($node.Server -ne $null)
    {
        #If the Deployment Setting already exists, then we just need to update them
        $addNewNodeFlag = $false
        $node.Server= $ServerName;
        $node.ConfigurationDatabase= $DatabaseName;
        $node.ApplicationName= $ApplicationName;
        $node.Redeploy= $RedeployFlag;
        $node.Register= $RegisterFlag;
        $node.RestartHostInstances= $RestartHostInstancesFlag;
    }
}
 
if($addNewNodeFlag -eq $true)
{
    #Add a PropertyGroup node if the Deployment Setting doesn't exist
    $newXmlPropertyGroup = $xml.CreateElement("PropertyGroup", "http://schemas.microsoft.com/developer/msbuild/2003")
    $newXmlPropertyGroup.SetAttribute(“Condition”,”'`$(Configuration)|`$(Platform)' == 'Debug|AnyCPU'”);
 
    $newXmlElement = $newXmlPropertyGroup.AppendChild($xml.CreateElement("Server", "http://schemas.microsoft.com/developer/msbuild/2003"));
    $newXmlTextNode = $newXmlElement.AppendChild($xml.CreateTextNode($ServerName));
 
    $newXmlElement = $newXmlPropertyGroup.AppendChild($xml.CreateElement("ConfigurationDatabase", "http://schemas.microsoft.com/developer/msbuild/2003"));
    $newXmlTextNode = $newXmlElement.AppendChild($xml.CreateTextNode($DatabaseName));
 
    $newXmlElement = $newXmlPropertyGroup.AppendChild($xml.CreateElement("ApplicationName", "http://schemas.microsoft.com/developer/msbuild/2003"));
    $newXmlTextNode = $newXmlElement.AppendChild($xml.CreateTextNode($ApplicationName));
 
    $newXmlElement = $newXmlPropertyGroup.AppendChild($xml.CreateElement("Redeploy", "http://schemas.microsoft.com/developer/msbuild/2003"));
    $newXmlTextNode = $newXmlElement.AppendChild($xml.CreateTextNode($RedeployFlag));
 
    $newXmlElement = $newXmlPropertyGroup.AppendChild($xml.CreateElement("Register", "http://schemas.microsoft.com/developer/msbuild/2003"));
    $newXmlTextNode = $newXmlElement.AppendChild($xml.CreateTextNode($RegisterFlag));
 
    $newXmlElement = $newXmlPropertyGroup.AppendChild($xml.CreateElement("RestartHostInstances", "http://schemas.microsoft.com/developer/msbuild/2003"));
    $newXmlTextNode = $newXmlElement.AppendChild($xml.CreateTextNode($RestartHostInstancesFlag));
 
    $xml.Project.InsertAfter($newXmlPropertyGroup, $xml.Project.PropertyGroup[1])
}

THIS POWERSHELL IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND.

You can download Visual Studio: Fixing BizTalk Project Deployment Properties with PowerShell from GitHub here: https://github.com/sandroasp/BizTalk-Server-Resources/tree/master/PowerShell-scripts/vs-Fixing-BizTalk-Project-Deployment-Properties

Stay tuned for the following BizTalk Server Best practices, Tips, and Tricks.

Back to Blog