Undeployment - why is all my host instances getting stopped?

Topics: Server Deployment
Feb 25, 2013 at 2:11 PM
I have a solution where I use BizTalk Deployment Framework (v5.0).

I have set the property <SkipHostInstancesRestart> to TRUE, and I haven't defined anything for the <BizTalkHosts> property.

Anyway, when i choose to Undeploy it's stopping all of my host instances. I do not want this to happen. The worse thing is that it does not start the instances after undeploy is finished.

Why is this happening? This is my .btdfproj file:

<?xml version="1.0" encoding="utf-8"?>
<!-- Deployment Framework for BizTalk 5.0 Copyright (C) 2004-2012 Thomas F. Abraham and Scott Colestock --> <!--<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Installer" ToolsVersion="4.0">--> <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Deploy">
<Configuration Condition="'$(Configuration)' == ''">Debug</Configuration>
<Platform Condition="'$(Platform)' == ''">x86</Platform>
<!-- Properties related to building an MSI for server deployments -->
<!-- BizTalk App Version Upgrade -->
<!--   For each new product release to be deployed to your BizTalk servers: -->
<!--     1) Increment ProductVersion -->
<!--     2) Generate a new GUID and update ProductId with the new GUID -->
<!--   This allows the new MSI to automatically uninstall (not undeploy!) the old MSI and install the new one. -->
<!-- BizTalk App Version Upgrade -->
<!-- NEVER change the ProductUpgradeCode. -->
<!-- Under TFS Team Build, set CustomizableOutDir property to true in TFS 2005/2008/2010 UpgradeTemplate. --> <!-- With a workflow build, copy the default template then modify the MSBuild task for the solution build. Set OutDir to blank and --> <!-- CommandLineArguments to String.Format("/p:SkipInvalidConfigurations=true;TeamBuildOutDir=""{0}"" {1}", BinariesDirectory, MSBuildArguments). --> <PropertyGroup Condition="'$(Configuration)' == 'Debug'">
<OutputPath Condition="'$(TeamBuildOutDir)' == ''">bin\Debug\</OutputPath>
<OutputPath Condition="'$(TeamBuildOutDir)' != ''">$(TeamBuildOutDir)</OutputPath>
<!-- We name our host(s) explicitly to avoid having the framework bounce them all. -->
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<OutputPath Condition="'$(TeamBuildOutDir)' == ''">bin\Release\</OutputPath>
<OutputPath Condition="'$(TeamBuildOutDir)' != ''">$(TeamBuildOutDir)</OutputPath>
<!-- We name our host(s) explicitly to avoid having the framework bounce them all. -->
<PropertyGroup Condition="'$(Configuration)' == 'Server'">
<!-- Get our PDBs into the GAC so we get file/line number information in stack traces. -->
<!-- We name our host(s) explicitly to avoid having the framework bounce them all. -->
<PropsFromEnvSettings Include="SsoAppUserGroup;SsoAppAdminGroup" />
<Schemas Include="MySchemas.dll">
<Import Project="$(DeploymentFrameworkTargetsPath)BizTalkDeploymentFramework.targets" />

Feb 26, 2013 at 6:51 AM
Does this happen on your development machine or just on the server? Try settings DeployPDBsToGac to false for ALL configurations. You have it true now for Server.

Mar 4, 2013 at 9:32 AM
Edited Mar 4, 2013 at 9:33 AM
  • Strange thing. We changed the setting for DeployPDBsToGAC to false for Server as you suggested and now it works fine. But I don't understand why it reads the settings under Server, when this is on our development machine?
Mar 5, 2013 at 5:15 AM
Any time you use a BTDF MSI to deploy you will be in the Server configuration. Any time you use the BTDF deployment tools within Visual Studio you'll be in Debug or Release configuration. When you're deploying on your development machine, which method are you using?

Mar 5, 2013 at 8:03 AM
Ok, now it makes sense and now I understand the differences of Debug/Release/Server.
We always generate the msi from BTDF in visual studio, and then we use the MSI to deploy afterwards.

But still a couple of questions:
  • Why does it have to stop the host instances at all when DeployPDBsToGAC is set to true?
  • And why aren't the instances started again in the end of the deployment?
Mar 7, 2013 at 7:04 PM
It has to stop the host instances because they will load the PDB's when present and lock them. Then we will fail on the next deploy due to the locked files. If you specify a list of hosts in a BizTalkHosts ItemGroup, only those listed will be stopped. As a result you could end up with the locked file issue if the hosts that are not restarted happened to load the PDB(s). The reason that the host instances are not restarted at the end is because that final step does use SkipHostInstancesRestart, which you have set to True.

So it all comes from the PDB's, and the easiest solution is to just disable that feature -- or use BizTalkHosts to indicate a host that is harmless to restart, maybe your dedicated Tracking host, assuming you have one.

Mar 7, 2013 at 7:26 PM
Thank's a lot for clearifying. It all seems very logic now, and we have solved all our issues until now. We're looking forward to deliver a much more simplified deployment routine to our operational guys :)

Mar 9, 2013 at 5:54 AM
Great, glad to hear it! I'm sure that your operational guys will be pleased.

Apr 3, 2014 at 3:54 AM
Just a follow-up to this issue -- in v6.0 DeployPdbsToGac will be set to false instead of true by default in new projects created with the Add New Project wizard and in the Framework's default initialization. I think it's better to opt-in to this behavior rather than have it enabled by default, because it does lead to longer outage times by stopping the host instances early in the deployment process instead of just a bounce at the end.