vbp 5.7 : visual build pro action spawns child with missing system macros?

[epu]

Hey dudes,

I'm having trouble with spawning a visual build pro instance (chained build). My system environment has 2 variables set, XDK and XEDK, which correspond to the paths to the Xenon and Xbox sdks.

The parent (spawner) project shows that these variables exist in the system macros. The child project shows that these variables do not exist in the system macros.

if I open a cmd.exe instance and type 'set X<enter>' these variables are set.

Is there a known bug with spawned vbp projects where the system macros are truncated? Is there a max length to the number of system macros that can be created?

Thanks for VBP,

-epu

[kinook]

There aren't any known problems or limits with that functionality. The chained process environment block will be inherited from the parent VBP process. Does the attached sample work properly (logging the XDK/XEDK environment variable values in both instances)?

Some things that could influence treatment of environment variables within VBP are

1) modification of 'Tools | Application Options | General | Include environment variables in system macros' (Application.Options.EnvVarsInSystemMacros in script code).

2) setting and/or deleting macros via a Set Macro action with 'Add to environment variables when calling external programs' checked.

3) Using the VBP object model to modify environment variables (see 'Environment Variables' section of the Advanced.bld sample).

[epu]

~~~~~~~~~~~~~
There aren't any known problems or limits with that functionality. The chained process environment block will be inherited from the parent VBP process. Does the attached sample work properly (logging the XDK/XEDK environment variable values in both instances)?
~~~~~~~~~~~~~

The test you gave me prints it out in the parent and the chained instance.

I'll see if I can reduce my error to a smaller test case; I have a lot of steps.

~~~~~~~~~~~~~
1) modification of 'Tools | Application Options | General | Include environment variables in system macros' (Application.Options.EnvVarsInSystemMacros in script code).
~~~~~~~~~~~~~

I don't modify this value in either parent or child.

~~~~~~~~~~~~~
2) setting and/or deleting macros via a Set Macro action with 'Add to environment variables when calling external programs' checked.
~~~~~~~~~~~~~

In the parent file, I load a large set of global macros when I start the project with a script action:

<code>
Application.Macros(vbldMacroGlobal).Load "%PROJDIR%\COMMON.macros"
</code>

adding this to the test case does not reproduce the problem.

I'll try simplifying my project until I have the smallest proj that still reproduces the error and get back to you.

Thanks,
-e

[epu]

disabling and enabling some steps sometimes makes this go away, but it's not clear what the culprit is. If I write out the all macros collection and pass it to the project as /macros MYMACROS.macros, this works around my problem. If I have time to troubleshoot this again, I will post my test case.

[epu]

sometimes, even though I write out all the macros correctly (inspection of macros in notepad shows XDK, XEDK are there), when loading the macros they load truncated.

If I stuff this
<code>
<step action='Run Script' type='1'>
<Language>VBScript</Language>
<Script><![CDATA[Application.Macros(vbldMacroAll).Save "%PROJDIR%\" & vbld_FormatDateTime() & ".%PROJROOT%.ALL.macros"
Application.Macros(vbldMacroSystem).Save "%PROJDIR%\" & vbld_FormatDateTime() & ".%PROJROOT%.SYSTEM.macros"
Application.Macros(vbldMacroGlobal).Save "%PROJDIR%\" & vbld_FormatDateTime() & ".%PROJROOT%.GLOBAL.macros"]]></Script>
<description>for debug / troubleshooting</description>
<indent type='3'>1</indent>
<name>export all macros</name>
</step>
</code>
just before I call the chained project, and then into the failure step of the chained project, I can inspect and see that they don't match. I'll try to load them in the chained sample and reproduce.

The SYSTEM macros versions obviously differ in the failed step macros of the chained proj.

the chained project has no TEMP or TMP macro, but the parent proj has them as
<code>
<macro>
<name>TEMP</name>
<description>Environment variable</description>
<value>C:\DOCUME~1\Z-AXIS~1\LOCALS~1\Temp</value>
</macro>
<macro>
<name>TMP</name>
<description>Environment variable</description>
<value>C:\DOCUME~1\Z-AXIS~1\LOCALS~1\Temp</value>
</macro>
</code>

there's some additional missing vars. I'll attach the system macros for your perusal. maybe they can help?

[epu]

if you need more macro dumps or there's a way to debug this (log more verbosely, get some other info) please let me know.

include environment variables in system vars was on; I'm disabling this to see if I get the same results.

Uh, now I know what this checkbox does ;)
I need the env vars on, since that's what XDK and friends are.
When I turn them off, the project can't build. When I re-enable them, the variables I am missing in the child project are also missing in the parent. That's kinda spooky. Please advise.

I am going to try re-installing.

[kinook]

Saving all macros and loading them as global macros in the chained project is not a good idea. Global macros take precedence over system macros, so any system macros in the parent project's 'all' collection will become global macros in the child instance, overriding the true system macro values there.

It would be much better to narrow down the original problem to a reproducible case that we can investigate here. Using v6, you could add project-level step script events to log the problem macros before and after each step to isolate when they are changing or getting deleted. In v5, you would have to add the script code to each step's script code (you can multi-select steps and edit step script, but it will replace any existing script code for those steps).

Also, please post the info from Help | About | Install Info. Thanks.

[epu]

Visual Build Professional 5.7
Registered to: Z-Axis, Ltd. (4-computer license)
Windows Version: 5.1.2600.2.0
Install path: C:\Program Files\VisBuildPro
cmax20u.dll version 2.1.0.21
SftTree_IX86_U_50.dll version 5.01
unins000.exe version 51.15.0.0
VisBuildBld.dll version 5.7.0.0
VisBuildCmd.exe version 5.7.0.0
VisBuildCore.dll version 5.7.0.0
VisBuildDotNET.dll version 5.7.0.0
VisBuildExt.dll version 5.7.0.0
VisBuildLog.dll version 5.7.0.0
VisBuildMisc.dll version 5.7.0.0
VisBuildMS.dll version 5.7.0.0
VisBuildNet.dll version 5.7.0.0
VisBuildPro.exe version 5.7.0.0
VisBuildSvr.dll version 5.7.0.0

[epu]

<quote>Using v6, you could add project-level step script events to log the problem macros before and after each step to isolate when they are changing or getting deleted.</quote>

the free v6 won't run my projects since they are lengthy. I don't think we're prepared to upgrade yet.

<quote>In v5, you would have to add the script code to each step's script code (you can multi-select steps and edit step script, but it will replace any existing script code for those steps).</quote>

I can use the save to write out the macros each step, and manually check for difference, but it would be nice to do a whole run up to where the problem happens, and diff the macro output between each step.

I'll save each macro collection on every step as (STEPNUM_MACROCOLLECTION.macros) where stepnum gets incremented every time the script runs.

Where DEBUG_STEPNUM is project macro starting at 1,

<code>
set stepNum=application.macros(vbldProject).Item("DEBUG_STEPNUM")
stepNum.Value = CInt(stepNum.Value)+1
set projDir=application.macros(vbldSystem).Item("PROJDIR")
set projRoot=application.macros(vbldSystem).Item("PROJROOT")
Application.Macros(vbldMacroTemporary).Save projDir.Value & "." & stepNum.Value & "." & projRoot.Value & ".TEMP.macros"
Application.Macros(vbldMacroProject).Save projDir.Value & "." & stepNum.Value & "." & projRoot.Value & ".PROJ.macros"
Application.Macros(vbldMacroGlobal).Save projDir.Value & "." & stepNum.Value & "." & projRoot.Value & ".GLOBAL.macros"
Application.Macros(vbldMacroSystem).Save projDir.Value & "." & stepNum.Value & "." & projRoot.Value & ".SYSTEM.macros"
</code>

[epu]

still looping through the continual build script. saving the macro values out on every step seems to be preventing the original issue (hasn't shown up yet). is there some kind of flush done on macros when you save them out that isn't done normally during a build, or a timing problem that the build script functionality is now masking out?

[kinook]

There isn't any "flushing" of macros when saved, and I'm not aware of an timing problems. System macros never get saved by VBP itself anyway.

You might try downloading and re-installing from http://www.kinook.com/Download/VisBuildPro57.exe. There was a patch for a bug where global macros on a network share were not always saved properly (although this wouldn't affect system macros so I doubt it would apply in your case).

Could you send your .bld file to support@kinook.com, describing exactly when and how things go bad when this problem occurs? Something about your project might stand out as something we could mimic here and try to investigate. Thanks.

[epu]

am downloading and will try re-install.
~~~ info now reads ~~~
Visual Build Professional 5.7
Registered to: Z-Axis, Ltd. (4-computer license)
Windows Version: 5.1.2600.2.0
Install path: C:\Program Files\VisBuildPro
cmax20u.dll version 2.1.0.21
SftTree_IX86_U_50.dll version 5.01
unins000.exe version 51.15.0.0
VisBuildBld.dll version 5.7.0.2
VisBuildCmd.exe version 5.7.0.1
VisBuildCore.dll version 5.7.0.2
VisBuildDotNET.dll version 5.7.0.2
VisBuildExt.dll version 5.7.0.3
VisBuildLog.dll version 5.7.0.1
VisBuildMisc.dll version 5.7.0.2
VisBuildMS.dll version 5.7.0.1
VisBuildNet.dll version 5.7.0.1
VisBuildPro.exe version 5.7.0.2
VisBuildSvr.dll version 5.7.0.2
~~~~~~~~~~~~~~~~~
All the visbuild.* files are newer versions.

Zipped and mailed projects for your debugging pleasure.
Rebuilding now.

[epu]

Hey kinook dudes,
I am still sometimes getting this error. The frequency seems less with the latest version of 5.7, but this is not based on hard facts. Have you had any luck debugging?

[kinook]

We have not been able to reproduce the problem you are seeing. One possible workaround:

1) In the parent project, pass the XDK/XEDK macros to the child (for instance, as _XDK and _XEDK).

2) At the beginning of the child project, add Set Macro steps to set XDK/XEDK temporary macros (marked to update env vars) to the values of _XDK/_XEDK only if the macros %XDK%/%XEDK% are undefined.

[epu]

thanks, of course I can pass them in. let me know if there are any changes for the better.