BTDF–(Best) Practices

 

Hereby a list of practices I now tend to follow after some experience with it, I have additional features that I will share in the future, but at the beginning of the project, please think about all (and more) settings such as;

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.

 

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 ‘Deployment\Tools’ 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">

 

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.

 

Feature requests

· Undeploy ESB itineraries

· Ability (or documentation how) to overwrite default settings (using parameters) such as;

‘StartApplicationOnDeploy’

- Do not GAC pipelinecomponents

 

 

 

Cheers,

Sander