Illegal macro value

[Kim]

Hi,
I'm using the FAILSTEP_OUTPUT macro when sending an email to developers when build fails.

When running NUnit tests, one of my projects failed and gave the following output (only included the failing text) : WaitMultiple(WaitHandle[] waitHandles)

When using this macro in the body of the send email step, the following error is returned: Error expanding macros in property Message: <Error parsing scripts: Unrecoverable Parse Error at position 301 - expecting section>

If the [] characters are manually removed from the macro value, no errors are generated. Are [] characters not allowed in macros? Is this a bug in VisBuildPro? Are there any workarounds?

I'm currently using version 5.5 of VisBuildPro.

[kinook]

Any special characters ([ ] %) in output captured from a step and stored in the LASTSTEP_OUTPUT/FAILSTEP_OUTPUT macros are normally doubled so that they will be treated as literals by VBP, rather than as script/macro markers. I've attached a sample that works as expected here (it creates a batch file which echos that string and the fails, calls the batch file, and then logs and send the failed step output in the failure steps). What is different about your scenario?

[Kim]

My NUnit output only contain a single [ char or ] char - no double [[ chars. The FAILSTEP_OUTPUT macro only contain single [ char. VBP do not double the special characters to [[ or ]].

[kinook]

Can you post a reproducible case for this? Any program output that is captured is treated as described above, so it's unclear how the macro could end up with such a value.

[Kim]

The case is 100% reproducable in my build environment (but you need my source code...). I have attached a screendump that shows the output with single [ and ] chars. This output is identical with the FAILSTEP_OUTPUT macro (since the build failed).

[kinook]

By the time the output is logged (as shown in the screenshot), the double chars have already been evaluated as a single literal bracket and just the single literal bracket chars are shown, which is the expected behavior. I don't see any macro expansion errors here. Please narrow your code down to a reproducible case that we can run here and also send the full log file of the build.

[Kim]

You are right - the problem is not the original FAILSTEP_OUTPUT macro. When a failure arise, my first failure step is to copy the FAILSTEP_OUTPUT macro to a temporary macro for safe keeping (another step failing and overwrite the original FAILSTEP_OUTPUT macro).

Original FAILSTEP_OUTPUT macro value:
System.Threading.WaitHandle.WaitAll(WaitHandle[[]] waitHandles)

Copy made: LAST_ERROR_MESSAGE temporary macro value:
System.Threading.WaitHandle.WaitAll(WaitHandle[] waitHandles)

The copy step is the first job in the failure steps, and is using a "Set Macro". The value of this step is %FAILSTEP_OUTPUT% which deletes the extra [ and ] chars. When using the copy in a send email step, an error arise.

Attached is a build script that can reproduce this failure

[kinook]

You need to check the 'Don't expand macros in value when setting' checkbox on the Macro tab of the Set Macro action. The expand logic also applies to script and doubled (literal) characters (we'll update the docs because this could be stated more clearly).

[Kim]

OK - but then I'm back where I started. The new temporary macro is pointing to the original macro. If the original macro change its value, the value inside the temporary macro will also change.

I need a backup of a macro value (in case the original macro change its value) and not a reference/pointer to the original macro value. How do I do that?

[kinook]

Sorry, duh! To copy the macro, you need to replace the Set Macro step with a Run Script step with the following (VBScript) code:

Application.Macros(vbldMacroTemporary).Add "LAST_ERROR_MESSAGE", Application.Macros(vbldMacroSystem)("FAILSTEP_OUTPUT").Value

to get the actual macro value without anything within *it* expanded/evaluated.

[Kim]

Thx - this code solved my problem