Using BTDF to Deploy Pure WCF Services

The BizTalk Deployment Framework (BTDF) is widely used as a tool for managing the complex deployment requirements for BizTalk Server integration solutions. With each iteration, it gets better & better. The latest version (still in Beta) now supports BizTalk Server 2013 R2.

Of course at Mexia we use this tool quite regularly for our clients, enjoying the simplicity it affords in automated deployment and management of environment-specific configuration. However, the ESB that we often provide our customers includes more than just BizTalk applications; it includes some services implemented in pure WCF. Although these services do utilise BAM for tracking and SSO for configuration management, those features do not require the empty BizTalk application that is generated from using the BTDF.

After consultation with BTDF author Thomas Abraham and some helpful tips on this thread, I spent some time putting together a BTDF project file that would deploy just the bits that are needed for WCF – and nothing more. It has been very successful so far, providing for a consistent build definition and deployment process across the entire ESB platform.  I’d like to share it with you here.

But before we go into the details, there are a few things you need to be aware of regarding this solution:

  • This applies only to version 5.5 of the BTDF; the new version (6.0) incorporates a complete rebuild of the IIS virtual directory provisioning, and therefore the VDIR code in this version is irrelevant. Since our client had already invested heavily in v5.5, I had to stay confined to that release (but I hope to rewrite this solution in v6.0 someday when I get a chance to play with it).
  • The IIS 6 Scripting Tools Windows feature must be enabled on your target system.

Setting the Project Options

When you first add a “Deployment Framework for BizTalk” project type to a solution, you are presented with a dialog allowing you to set a number of framework options. The items highlighted in yellow in this screenshot are the properties that you should change from their default settings:

InitialPropsDialog

However, this isn’t a comprehensive list of all the options; therefore I’ve included below the initial <PropertyGroup> listing from one of my project files to show the additional options that must be set:

<PropertyGroup>
<Configuration Condition=”‘$(Configuration)’ == ””>Debug</Configuration>
<Platform Condition=”‘$(Platform)’ == ””>x86</Platform>
<SchemaVersion>1.0</SchemaVersion>
<ProjectName>YOUR_PROJECT_NAME_HERE</ProjectName>
<ProjectVersion>1.0</ProjectVersion>
<IncludeSchemas>False</IncludeSchemas>
<IncludeOrchestrations>False</IncludeOrchestrations>
<IncludeTransforms>False</IncludeTransforms>
<IncludeMessagingBindings>False</IncludeMessagingBindings>
<IncludeSSO>True</IncludeSSO>
<IncludeVirtualDirectories>True</IncludeVirtualDirectories>
<UndeployIISArtifacts>True</UndeployIISArtifacts>
<ModifyNTFSPermissionsOnVDirPaths>True</ModifyNTFSPermissionsOnVDirPaths>
<UsingMasterBindings>False</UsingMasterBindings>
<RequireXmlPreprocessDirectives>False</RequireXmlPreprocessDirectives>
<ApplyXmlEscape>False</ApplyXmlEscape>
<SkipHostInstancesRestart>True</SkipHostInstancesRestart>
<StartApplicationOnDeploy>False</StartApplicationOnDeploy>
<EnableAllReceiveLocationsOnDeploy>False</EnableAllReceiveLocationsOnDeploy>
<StartReferencedApplicationsOnDeploy>False</StartReferencedApplicationsOnDeploy>
</PropertyGroup>

Overriding the Default Targets

The key to understanding this solution is to be aware of the default MSBuild targets that are installed with BTDF and imported into every BTDF project file, using this line of code (near the bottom of the generated Deployment.btdfproj file):

<Import Project=”$(DeploymentFrameworkTargetsPath)BizTalkDeploymentFramework.targets” />

The BizTalkDeploymentFramework.targets file is located in the MSBuild folder, typically at  “C:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0”.   There are two key items that establish the dependencies of both the Deploy and Undeploy targets:

  • <DeployDependsOn>
  • <UndeployDependsOn>
    Each of these elements contains a delimited list of targets.

Thomas pointed out that you can override these elements in your own individual project file, which is key to controlling the target dependencies. Simply by removing the targets that are specific to BizTalk applications, you can restrict the build to containing just the items that are needed for WCF service deployment.

Simply add the following <PropertyGroup> block after the <Import> statement mentioned above:

  <PropertyGroup>

<!--  THE FOLLOWING DEPLOY DEPENDENCIES HAVE BEEN REMOVED:      DeployAppDefinition;PreprocessBindings;ImportBindings;ConditionalHostStop;
TerminateServiceInstancesConditional;DeployFileAdapterPhysicalPaths;      DeploySchemas;DeployPipelineComponents;DeployPipelines;DeployTransforms;
DeployOrchestrations;DeployVocabAndRules;DeployCustomFunctoids;
      DeployEsbItineraries;DeployBtsNtSvcExeConfig;StartApplication;
CustomPostDeployTarget;BounceBizTalk;
    -->

    <DeployDependsOn>

      CustomPreInitialize;
      FrameworkInitialize;
      CustomPostInitialize;
      PreprocessFiles;
      PreprocessAndConfigureLog4net;
      CustomDeployTarget;
      DeploySharedAssemblies;
      DeployExternalAssemblies;
      DeployComponents;
      DeployVDirs;
      DeploySSO;
      DeployBam;
      CustomPostDeployTarget;
      CustomFinalDeploy

    </DeployDependsOn>

<!-- THE FOLLOWING UNDEPLOY DEPENDENCIES HAVE BEEN REMOVED:      PrepareAppForUndeploy;ConditionalHostStop;UndeployBtsNtSvcExeConfig;
UndeployEsbItineraries;UndeploySchemas;UndeployOrchestrations;
UndeployTransforms;
UndeployPipelines;UndeployPipelineComponents;
UndeployCustomFunctoids;UndeployAppDefinition;
UndeployFileAdapterPhysicalPaths;BounceBizTalk;
  -->

    <UndeployDependsOn>

      CustomPreInitialize;
      FrameworkInitialize;
      CustomPostInitialize;
      CustomUndeployTarget;
      UndeployBam;
      UndeployComponents;
      UndeployExternalAssemblies;
      UndeploySharedAssemblies;
      UndeployVDirs;
      UndeployVocabAndRules;
      UndeploySSO;
      CustomPostUndeployTarget;
      CustomFinalUndeploy

    </UndeployDependsOn>

  </PropertyGroup>

I’ve included the removed elements in the commented blocks so you can see what exactly has been overridden. Feel free to adjust this list to suit your individual project purposes. Searching the BizTalkDeploymentFramework.targets file will show you what functionality is included in each of these targets.

Creating the IIS Bits

Next, simply use the out-of-the-box bits of the BTDF to arrange the setting up of your virtual directory and application pool.  Note the this part has changed radically in version 6.0 of the BTDF – so please consult the documentation for learning about the new virtual directory handling in that version.

Although this is optional, I like to include a custom <PropertyGroup> section where I define some global variables:

<PropertyGroup>
<VirtualDirectoryName>YOUR_VIRTUAL_DIRECTORY_NAME</VirtualDirectoryName>
<AppPoolName>YOUR_APP_POOL_NAME</AppPoolName>
<WcfHostProjectPath>..\RELATIVE_PATH_TO_WEB_ARTEFACTS</WcfHostProjectPath>
</PropertyGroup>

Then I can reference these in the relevant VDIR bits:

<ItemGroup>
<IisAppPools Include=”$(AppPoolName)” />
</ItemGroup>
<ItemGroup>
<VDirList Include=”*”>
<Vdir>$(VirtualDirectoryName)</Vdir>
<Physdir>$(WcfHostProjectPath)</Physdir>
<AppPool>$(AppPoolName)</AppPool>
<AppPoolNetVersion>v4.0</AppPoolNetVersion>
</VDirList>
</ItemGroup>

<Target Name=”CustomPostDeployTarget”>
<PropertyGroup>
<AppCmd>%SystemRoot%\System32\inetsrv\AppCmd.exe</AppCmd>
</PropertyGroup>

  <Message Text=”Setting the AppPools to Integrated .NET v4.0…” Importance=”High” />
<Exec Command=”&quot;$(AppCmd)&quot; set apppool &quot;$(AppPoolName)&quot; /managedPipelineMode:Integrated /managedRuntimeVersion:v4.0″ Condition=”‘$(IisMajorVersion)’ == ‘7’” />

</Target>

Be aware that nested virtual directories are not supported in version 5.5.

Don’t forget to add the VDIR_UserName and VDIR_PassName items to your environment settings list and in your SettingsFileGenerator.xml spreadsheet!

<ItemGroup>
<PropsFromEnvSettings Include=”SsoAppUserGroup;SsoAppAdminGroup;VDIR_UserName;VDIR_UserPass” />
</ItemGroup>

And that’s it! Your BTDF project will now deploy your WCF service along with any environment settings (e.g. configuration values stored in SSO) without creating a BizTalk application.

Happy deploying!!

About Dan Toomey
Husband, father, Enterprise integration geek, Microsoft Azure MVP, Pluralsight author, Brisbane Azure User Group leader (@BrisbaneAzureUG), MCPD, MCT, MCTS & former professional musician.

9 Responses to Using BTDF to Deploy Pure WCF Services

  1. Hi Dan, thanks for writing this up. One correction: you wrote “The BizTalkDeploymentFramework.ServerExecute.targets file is located in the BTDF installation folder, typically at C:\Program Files (x86)\Deployment Framework for BizTalk 5.5\Framework.” You’re actually talking about BizTalkDeploymentFramework.targets which is located in C:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0. Regards, Tom

  2. Thanks for this post, Dan. It just helped me deploy a custom adapter using BTDF without creating any other BizTalk stuff :).

  3. Pingback: Using BTDF to deploy pure WCF services | Coding Bridges

  4. Anoop says:

    Thanks for the post. Great help.

    Is it possible to change the WCF service config file contents, like endpoints address etc while deploying in different env? How do we use SettingsFileGenerator to keep the endpoint address as per environments and replace in the web.config when the Service is deployed on IIS ?

    • Dan Toomey says:

      Hi Anoop,

      Yes, it certainly is possible. I”m quite sure that we’ve done this on our projects before. You simply insert the placeholder tokens (e.g. “$(myEnvVariable)”) into your Web.config and make sure that you have:

      • – defined the variable in your SettingsFileGenerator.xml file
      • – included the WCF service virtual directory definition in the PropertyGroup (as discussed in this article)
      • – ensured that the WCF artefacts (including the Web.config file) is copied to the project output folder by using the CustomRedist section

      If it doesn’t work for you, please send me your *.btdfprof file and I’ll have a look.

      • Mattias says:

        Hi, this might be to much to ask, but after Reading this good article I still have a problem to get it work with getting the Web.config paramters replaced från settingparameterfile.

        When I perform the following steps
        – Create msi (its created fine)
        – Deploy msi (its deployed fine, also performing “BizTalk deploy part and pointout the settings for env”)
        – Browsing the service .svc works fine
        – Looking in web.config I still have the address-tag unchanged. Meybe it has to do with the CustomRedist -part which I do not understand how to ….

      • Dan Toomey says:

        Hi Mattias,
        Looks like part of your post has been truncated. I’ll email you so you can continue the conversation offline.
        Cheers,
        Dan

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

John Glisson - Geek of the Cloth

Thoughts on integration, technology and what-not...

prashantbiztalkblogs

My BizTalk Experiences

The CRUCIBLE

THINK: It's not illegal....yet.....

paulbouwer.com

life and technology

Abdul Rafay's BizTalk Blog

My experiences with BizTalk related to architecture, development and performance in my enterprise.

Mike Diiorio

Connected Systems and other thoughts

BizTalk musings

Issues, patterns and useful tips for BizTalk development

EAI Guy.net

Enterprise Applicaiton Integration and SOA 2.0

Connected Pawns

Mainly BizTalk & Little Chess

Man Vs. Machine

Why can't we all just get along?

Adventures inside the Message Box

BizTalk, Azure, and other tools in the Microsoft stack - Johann Cooper

Biz(Talk)2

Talk, talk and more talk about BizTalk

Richard Seroter's Architecture Musings

Blog Featuring Code, Thoughts, and Experiences with Software and Services

Sandro Pereira BizTalk Blog

My notes about BizTalk Server 2004, 2006, 2006 R2, 2009, 2010, 2013 and now also Windows Azure BizTalk Services.

BizTalk Events

Calendar of BizTalk events all over the world!

Mind Over Messaging

Musings on BizTalk, Azure, WCF, and Enterprise Integration

The WordPress.com Blog

The latest news on WordPress.com and the WordPress community.

%d bloggers like this: