use of "ifdef" in binding file

Topics: Bindings File, Settings Management and SSO
Dec 30, 2009 at 1:52 PM

 

Documentation shows to do an "ifdef" like this:

<!-- ifdef ${ _xml_preprocess} -->

<!-- <Address>${FileSendLocation}\%MessageID%.xml</Address> -->

<!-- else -->

<Address>C:\temp\BizTalkSample_OutDir\%MessageID%.xml</Address>

<!-- endif -->

 

What are the reasons for not doing it this way?

<Address>

 <!-- ifdef ${ _xml_preprocess} -->

<!-- ${FileSendLocation} -->

<!-- else -->

 C:\temp\BizTalkSample_OutDir

<!-- endif -->

\%MessageID%.xml</Address>

 

My guess is that you want the binding file to work even without running the preprocessor? If so, when would that ever be used? Once we commit to using BTDF, when we ever want to use the binding file without the preprocessor?

If we always assume the preprocessor will run, could the entire ifdef/else/endif be dropped, and we could just use the substitution, like this:

<Address>${FileSendLocation}\%MessageID%.xml</Address>

The reason I ask is that doing it this way would allow a person to re-lace the binding file in a much-much shorter time, or even use a mass find/replace utility to do it.

Thanks,

Neal Walters







Coordinator
Dec 30, 2009 at 5:56 PM
Edited Dec 30, 2009 at 5:59 PM

The newest versions of xmlpreprocess support removing the #ifdef syntax altogether, though that version hasn't yet been pulled into the BTDF.

There was a time in the framework when preprocessing wasn't assumed to always run for developers (and you wanted the file to be usable without any changes), but most folks prefer to always pre-process now.

Jun 17, 2010 at 1:10 PM

Downloading version 2.0.12.0, replacing the exe file and adding "/n" to the call to xmlpreprocess.exe file (C:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0\BizTalkDeploymentFramework.targets) indeed does the trick. thanks!

 

Coordinator
Jun 17, 2010 at 3:35 PM

Thanks for the update.  The Deployment Framework currently includes XmlPreprocess 2.0.11.0, which also supports the /n parameter.  I'll have to update to include 2.0.12.0 for the next release.

Thanks,
Tom