My last post on the BizTalk Deployment Framework contained screenshots from my slidedeck. I've updated this deck and stripped out the bits i can't share. See the additional information on each slide on: http://snefs.blogspot.nl/2013/09/biztalk-deployment-framework-things-to.html

1. BIZTALK
DEPLOYMENT
FRAMEWORK
(BTDF)
SANDER NEFS

2. CLASSIC DEPLOYMENT VS
BTDF
MSI
• Pro
• Commonly known by BizTalk developers
• Cons
• Manual deployment / package creation of (non) BizTalk
artefacts
• Custom scripts required for a lot of tasks
• No Automated deployment / logging  scripts required
• No standard approach to handle multiple server
deployment / bindings / redeploy / full server install etc
BTDF
• Pro
• Components already developed, available Highly
customizable / flexible
• Automated package creation of (all) artefacts, generated
Wix MSI
• Lot’s of online resources / documentation on- and offline
available
• Cons
• Learning curve to fully use capabilities

3. BTDF FEATURES
• Actively maintained / supported!
• Support for BizTalk Server 2006, 2006 R2, 2009, 2010 and 2013 and BizTalk ESB Toolkit 2.x on both 32- and 64-bit Windows
• Integration with Visual Studio 2005/2008/2010/2012 menus, toolbars and output window, plus
• Templated bindings file processing that automatically targets multiple runtime environments from a single bindings file
• Extensibility through user-defined MSBuild targets and tasks (e.g. Database deployment)
• Support for deployment of various BizTalk artifacts including:
• Messaging bindings / Orchestrations / Schemas / Maps / Pipelines / Custom components (DLL's) / Custom pipeline components / Custom functoids / Rules / and
vocabularies / IIS virtual directories / Single Sign-On (SSO) applications / BAM activities / ESB Toolkit itineraries / Configuration settings infrastructure including user-
friendly settings management spreadsheet,
• Full and Fast deployment modes to reduce development cycle time
• Automated packaging of entire application into standard Windows Installer MSI file
• Automated restart of one or more BizTalk host instances and IIS or selected AppPools
• Automatic addition of BizTalk application references
• Automation of the entire BizTalk application deployment and update processes
• Support for Windows XP, Vista and 7 and Windows Server 2003 through 2008 R2
• IntelliSense and Add New Project wizard
• NET API for settings access at runtime and custom ESB Resolver
• Detailed logging for informational and troubleshooting purposes

4. CONSIDERATIONS
ADMINISTRATOR
• BizTalk Administrator must learn a
new way of deployment /
administration!
• Full deploy of all projects can be
scripted (undeploy, deploy) fairly
easy
DEVELOPER
• Deployment is not based on Xml
config .Config instead of user setting
in VS.Net project file (if it deploys on
my machine…it does on yours…)
• .BTDF projects are not a known type
in VS.Net, add the files manually in
the solution
• Alignment of procedures with
Administrator is essential
General
 1 .Net Solution is typically mapped
to 1 BTDF Project which leads to
an BizTalk Application

5. BIZTALK
DEPLOYMENT
FRAMEWORK
Usage

6. HOW TO USE
DESIGN TIME RUN TIME
Deployment
MSI
Build
Server
VS.Net

7. BIZTALK
DEPLOYMENT
FRAMEWORK
Guidelines

8. HOW TO USE (BIZTALK 2013)
• Install the 5.1 beta 2 (latest at this moment)
• Open the BizTalk solution
• Create a new project ‘Deployment’ 
• Select the items to be part of the deployment
• Tick ‘Only write values different from default’ 
http://www.tfabraham.com/BTDFDocs/V5_0/

9. HOW TO USE (BIZTALK 2013)
• Nothing is shown?
• Create a ‘Deployment’ folder
• Add the items 
• Important files
• Deployment.btdfproj
• Configuration
• SettingsFileGenerator.xml (excel file)
• Contains all the settings
http://www.tfabraham.com/BTDFDocs/V5_0/

10. CONCEPTS
• SettingsFileGenerator
• Configure settings per environment
• Settings are stored in SSO
• MasterBindings
• Bindings are modified with macro’s (e.g. URI), the URI is dynamically
set based on the selected environment
• Approach: No Masterbindings  Each environment will have a
‘dedicated bindings’ file
• MSBuild is used to perform the actions (all settings can be overridden

11. CONCEPTS
• Deployment.btdfproj (xml config file)
• PropertyGroup (1) with solution name / BTS application name
• Settings per artefact type (deploy maps, schemas etc)
• PropertyGroup (2) with MSI file name guid etc

12. CONCEPTS
• Deployment.btdfproj (xml config file)
• Additional / Custom PropertyGroups per build type
• ItemGroup (actual configuration of artefacts)

13. DEDICATED BINDINGS (1-3)
• Open the Settingsfile
• Specify the Bindingsfile for the environment

14. DEDICATED BINDINGS (2-3)
• Add the BINDINGS in the Solution folder
• Define to use the bindingsFileName from Excel as a property

15. DEDICATED BINDINGS (3-3)
• Add the BINDINGS in the BTDF
‘ItemGroup’ Additional files element

16. 2 STEP DEPLOY/UNDEPLOY
• Consider a multi-dependent solution with a
‘decoupled’canonical model

17. UPDATING A REFERENCED APP
• How to update the
Common?
• Replace common is
not possible
• Remove the
dependencies delete
apps
• Versioning (complex &
timeconsuming)

18. UPDATING A REFERENCED
APP(BTDF)
• Redeploy based on
already deployed
environment
• Most of the steps can
easily be automated
• Consistency in
deployment

19. BIZTALK
DEPLOYMENT
FRAMEWORK
HelloWorld Application – suggested starting point

20. LAB: ‘HELLOWORLD’
• Install the 5.+ BTDF version on your environment
• Start the tutorial:
• ‘Create a Deployment Project for the HelloWorld Application’
• Goals
• Learn to use the Deployment Framework for BizTalk's Add New Project wizard
• Customize a Deployment Framework project file in the Visual Studio editor using
IntelliSense
• Configure an XML bindings file for use with the Deployment Framework project
• Deploy the application as a developer using the Deployment Framework's Visual
Studio integration
• Build a Deployment Framework MSI for deployment to a BizTalk server
• Deploy the MSI to the local machine as if it were a BizTalk server

21. GUIDELINES - I
Choice: Disable starting of ports etc
<StartApplicationOnDeploy>False</StartApplicationOnDeploy>
<StartReferencedApplicationsOnDeploy>False</StartReferencedApplicationsOnDeploy>
<EnableAllReceiveLocationsOnDeploy>False</EnableAllReceiveLocationsOnDeploy>
Rationale: Starting applications is useful on dev/test not on accp/prod)
Note: These settings are part of the ‘standard’ settings, which to my knowledge cannot be overwritten, therefore you should
choose the safest option.
Choice: Always use masterbindings
Rationale: Standardisation, in all application you will use, there will be some ports that use masterbindings. If this is used from
the start all projects will have the same structure. In most of the case you will end up using them.
Choice: Do not use XmlEscape
Rationale: Xml Escape will modify the binding file (by unescaping the file using a adapterXpaths.txt file in the BTDF folder), the
configuration .txt file does not include all possible xml escaped values such as WCF adapter settings, inflicting manual
changes…which means customizations…which i do not favor.
Additionally this is a hassle when using Send ports filters and making modifications, as you have to manually change the
exported bindings from XmlEscaped to unescaped…..not really ideal.
Choice: SkipIIS/Host instance restart (include in manual)
Rationale: If (this needs to be though over) you have multiple applications, it’s likely that it’s not usefull to restart IIS/Host
instances as this would be done for each application.

22. GUIDELINES - II
Choice: Use SSO - Settingfiles
Rationale: Standardisation - All settings that are required in your application should be stored in SSO, the BTDF can retrieve them in various
components
Choice: Use project name <Deployment> instead of <projectname>.deployment
Rationale: Standardisation, this makes it very easy to script deployments when multiple applications are used
Choice: Only configure values that are overwritten
Rationale: This prevents very long configuration files. In most project the defaults are suitable, and once a settings is required (due to a
project type) adding the setting is fairly easy.
Choice: Create folder in Project ‘DeploymentTools’ and add all tools
Rationale: Once the BTDF project has been created, you need to add all files such as (bindings, settingsfile generator, tools etc), this allows
you to add this to TFS which enables co-developers to quickly build the project
Choice: Change the toolsversion (only after error: SDC 2006 error)
Rationale: If you receive an error on SDC Task (when using FILE tasks)
Original configuration
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Installer" ToolsVersion="4.0">
New configuration
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Deploy">

23. GUIDELINES - III
Choice: Do I need the BTDF?
Rationale: Yes , I think in most scenarios you do, you must wonder if the learning curve for a newbie is worth the
advantage. For example, a POC which lasts for a couple of days, the learning curve might not be useful.
Choice: We will need to define each project if there is more than 1 project of the same type
Rationale: the deployment framework assumes certain naming conventions and allows you to have a short .BTDF
project file (only deviations needs to be specified), however, if you have multiple projects, you need to specify them
all! (1 project .Schemas would mean no config, an additional project ‘External.Schemas’ would mean we need to
define both Schemas projects in an ItemGroup
Feature requests
· Undeploy ESB itineraries
· Ability (or documentation how) to overwrite default settings (using parameters) such as;
‘StartApplicationOnDeploy’
- Do not GAC pipelinecomponents