Setting environment variables before a remote project is run

[dalevine]

I am using one VBP script to execute a VBP script running on a remote VM. Before executing the script I would like to run a batch file, like VCVARS32.BAT so that the environment is set before I start. If I cannot do this then I must use the "Command To Run Before main command" for each external build. This is error prone.

Is there any way to directly establish the enviroment?

Thanks

[kinook]

Make the project that is invoked remotely a stub, which just builds the main project and runs vcvars32.bat before the main command.

[dalevine]

Interesting idea.

So there would be three VBP projects:
1. A VBP on the CI server that invokes the build on the remote VM. This project passes a lot of macro properties to the remote project.

2. The stub, which runs vcvars32.bat, and which retransmits the macro properties to the "real" project.

3. The "real" project, which uses the properties.

Next question: is there any way for the stub to simply pass-thru whatever arguments are passed to it to the "real" VBP without needing to explicitly define each one?

This way I can add properties to VBP1 on the server side and used by VBP3 without being required to modify the stub VBP2?

Thanks so much for you assistance.

[dalevine]

I think I answered my own question. I think this script will work...

For Each macro in vbld_TempMacros()
Builder.LogMessage ( "Found temp macro = " & macro.Name & ", Value= " & macro.Value )
Set objMacro = Application.Project.Macros.Add( macro.Name, macro.Value, ,,True )
objMacro.Value = macro.Value
Next

[kinook]

http://www.kinook.com/Forum/showthre...?threadid=4081

[dalevine]

I'm glad you posted that link, I am using the method shown there.

I ran into a problem marking the temporary variables as environment, as shown here.

"
For Each macro in vbld_TempMacros()
Builder.LogMessage ( "Found temp macro = " & macro.Name & ", Value= " & macro.Value )
macro.AddAsEnvVar = True
Next
"

I chained to the other VBP , using the "Pause at first step for debugging" option. The first time the chained VBP was invoked none of the macros appeared in the chained VBP. If I then exited the project and reran the action, all the macros appeared.

I don't know if the problem only occurs when debugging the project, but I wanted you to know about the bug.

[kinook]

See the 'Create via script' step in the Advanced.bld sample.

[vlad2135]

AddSetMacroStep objApp.Project, macro.Name, macro.Value
does not work for me
I'm doing everyting like in the sample and later in the build trying to output macros value from the cmd file:
echo %MY_TEST%

I got nothing.

What am I trying to achieve - I'm trying to separate my global macros into two files - one is global global , and another is specific for each vendor (it will contain stuff like COMPANY_NAME etc...).

So far I was not able to achieve this because Visual Build do not export macros loaded during build to environment.

I load macros like this:
Application.Macros(vbldMacroGlobal).Load "c:\FULLPATH\vendor.macros"

And then iterate all macros:
For Each macro in vbld_AllMacros()
AddSetMacroStep .......
Next

And then run test.cmd:
echo %MY_TEST%

I got ECHO is on.

On the second run everything is OK because new global macros are exported to environment.

So I've tried to restart build from itself, but failed too:
Builder.Stop or Builder.ResetBuildStatus did not help me.

Any advice for my problem?

[kinook]

See attached sample.

[vlad2135]

Thanks a lot for prompt reply. Yes, your sample works but I've managed to modify it according to my requirements and reproduce the problem.

As I've said before, I load all macros from xml file into global macros. After that I iterate output of vbld_AllMacros() function (crucial!!) and add steps to temporary project.
This way it does not work!

But if I load macros from file into temporary macros and iterate vbld_TempMacros(), then everything works just fine!

But I need to import my macros as globals, because they must have lowest priority to be able to be overloaded by project macros.

Anyway, your project, modified and not working, attached to this post. Also source macros file and test cmd file (just for the sake of problem report completeness). You'll only have to remove\replace absolute paths to these files.

[kinook]

Not sure why you would want to iterate over all macros (including system, which could cause problems). Try using Application.Macros(vbldMacroGlobal) instead.

[vlad2135]

Oh, so easy, thanks a lot! I was using vbld_AllMacros() because I did not know better. Sample code in this thread used vbld_TempMacros(), and I did not figured out that Application.Macros(vbldMacroTemporary) (and, therefore, vbldMacroGlobal) gives exactly the same result!

Thanks a lot for your help, Visual Build is the best!

PS: But I still think that VB could behave better (throw error or something) in the sample I posted

[kinook]

The SyncBuild method returns the result of the build. Check it and fail the step accordingly. Enable file logging in the child project to get error information.
http://www.kinook.com/VisBuildPro/Ma...uildmethod.htm
http://www.kinook.com/VisBuildPro/Ma...usproperty.htm
http://www.kinook.com/VisBuildPro/Manual/runscript.htm
http://www.kinook.com/VisBuildPro/Ma...ildlogging.htm

[vlad2135]

I've finally understand the source of the problem.

When ones creates temporary project, it does not have access to macros defined in the original project, it has access to global macros only.

And then, 'Set macro' step fails because my macros loaded from external file requires some macros from project file.
It is strange that I can not force temporary project not to fail by setting objStep.ContinueOnFailure = True and objStep.BuildFailureStepsOnFailure = False in the Function CreateStep - internal build fails anyway.

Anyway, now I have all information required to make this work, the only problem is to decide - are all those new complications and requirements worth it?

I was simply trying to split global macros file into two parts...

[kinook]

See the attached project for another approach to this that doesn't use a separate generated project.