...
NOTE: these are very close the buildFile=local scripts with a few changes. Of course the big one is this:
<Select BuildFile="local" />
---
<Select BuildFile="global" />
I also change Library; I set it to deployFolder to simplify project-cross-references and linking to the stub framework.
<Select Library="%DeployFolder%" />
Finally the Seledct.Local is modified so that FromCode IDF files generated for BuildFile=local translations are separate from the ones generated for BuildFile=global translations. This is a best practice if you are running multiple translations in the same workspace.
<Select Local="%ProjFolder%\idf\%TaskTag%" />
| Info |
|---|
You may also use a ScriptRules file to allow one script template to conditionally produce both local and global actual scripts: | Code Block |
|---|
| Create a ScriptRule to conditionally author either local or global stubbing commands:
FILE: usr\StandardUpgrade.Rules.xml
<ScriptRule id="SupportFramework">
<!--
Support Framework Conventions
-->
<Option Condition="'%TaskTag%'=='std'">
<Select BuildFile="local"/>
<Select Library="%RuntimeFolder%" />
<Select Local="%ProjFolder%\idf\%TaskTag%" />
</Option>
<Option Condition="'%TaskTag%'!='std'">
<Select BuildFile="global"/>
<Select Library="%DeployFolder%" />
<Select Local="%ProjFolder%\idf\%TaskTag%" />
</Option>
</ScriptRule>
...
Reference the SupportFramework rule in the template translation script. This ScriptRule
element may replace the BuildFile and Library commands normally placed in the file.
FILE: MigName.std.Tran.xml
<!-- Translation options -->
<Select GlobalSettings="%UserFolder%\GlobalSettings.xml" />
<Select Progress="1" />
<Select DevEnv="%DevEnv%" />
<Select Dialect="%Dialect%" />
<Select OptionalArguments="on" />
<Select DeployLocation="%NetProjFolder%" />
<Registry type="GUID" source="Project" target="{%TaskGuid%}"/>
<ScriptRule id="SupportFramework" FileName="..\usr\StandardUpgrade.Rules.xml" /> <--- add this |
|
...