Multi-conditional steps
 

Hi

I'm working on my very first build process and my brain has gone into a (newarly terminal) loop over this. Help please

What I'm trying to do is,

* Build a VB project
* if the output string contains "not building (no changes)..." log a message saying that the build was skipped
* if the output string doesn't contain that and the status is 0 then log a message saying "build successful"
* if the status isn't 0 and the output string contains "compatibility error " then jump to another sub routine that'll handle that situation
* if the status isn't 0 and the output string is anything else then go to a subroutine that'll log the failure and end the build.

It seems that what I need is to capture both the StepStatus and StepOutput (into temporary macros) at the same time but I can't see a way to do this.

I assume I'm missing something obvious but as I say I have a brain failure.

Any ideas?

Cheers

Sam

Attached is an example that does what you are describing. Also demonstrates using vbscript, subroutines and overrides (the subroutine name in the Execute appropriate subroutine step).

Note that Visual Build Professional provides much of the requested capability (logging success/failure, failure steps), so some of this seems a bit redundant...

Cheers Kevin

Here is UK it's home time now but I'll have a look tomorrow morning.


Regards

Sam

After posting this, I feel it is necessary to emphasize that this really isn't the "right" way to handle step success/failure/output. My example was intended to demonstate script and subroutine usage in Visual Build Professional and not to introduce a way to complicate what should be a very simple build!

Visual Build Professional already handles the different outcomes of the Make VB6 step (as well as other actions) by logging an appropriate entry, and terminating the build if/when an error occurs (unless Ignore Failure is set).

In the case of not building, or success, your concept essentially repeats that same log message (redundantly).

If the step fails to build, the build will stop anyway, so handling this manually is also redundant.

Finally, instead of trying to create a special subroutine to handle compatibility errors, build with project compatibility instead (set the Set version compatibility before building: to "Project Compability", and check the "Set projects to binary compatibility after building" checkbox). This will resolve most compatibility issues.

I don't want to sound critical of your idea, but rather to mention that your request works around the capabilities already present in Visual Build Professional for the very same purposes.

Hi Kevin

Thanks for that feedback, it was very helpful. Let me explain my difficulties here.

The system that we are talking about here is a production system worked on by a team of developers, so we cannot consider using project compatibility. Our system here has nearly 90 individual modules and many of these reference the DLL's/Ocx's which are in the build so we cannot "muck about" with the interface GUIDS or the whole thing falls apart. The order of compiles within the build is absolutely critical.

So, I have all the compiles done with binary compatibility. When a code change causes binary compatibility to be broken then my subroutine compiles with no compatibility. This is followed by a custom action step which works out the GUID of this new compiled DLL or OCX then updates all 90 of the VB Project files to set the reference to this new GUID (after an Unregister step before the compile and a Register step after it). This is all neccessary to keep the registry form filling up with rubbish,

I want the the build to stop only when one of the compiles fails because of (say) a syntax error, otherwise I want the whole thing to happen automatically (which was the business case for buying the licence).

Is there an in-built way that VBP could handle this?

In relation to your comment about logging, yes VBP does log but there is so much stuff in the log that the key events can be difficult to see so I've included extra "Log Event" steps to make it easier to read. Is there any way to reduce the "verbosity" of the log?

Cheers

Sam

The VBP way to handle VB compatibility builds is to specify a project group file (VBG) which contains all dependent projects in the Make VB6 action, and build with project or no compatibility (it will ensure proper build order and automatically fix up references within the group, see [1] and [2] for more details).

One extension to this that you might consider if binary compatibility will usually succeed is to have two Make VB6 steps, the first set to ignore failure and binary compatibility, the next to not ignore failure and set project compatibility, with a build rule to build only if the %LASTSTEP_STATUS% is not 0 (or using a more complex expression that looks specifically for compatibility compilation errors in %LASTSTEP_OUTPUT%).

Regarding build log verbosity, if you use the XML log format (Tools | Application Options | Logging) and the Transform XML Log action (which generates an HTML report from the XML log), you can configure the report as to which types of steps (succeeded, failed, etc.) and the amount of step output to include for each step. The report is also formatted in a more readable format than a plain text log file. It's also possible to entirely disable logging for one or more steps. See the Logging.bld sample and [3] and [4] for more details on these features.


[1] http://www.kinook.com/Forum/showthread.php?threadid=57
[2] http://www.visualbuild.com/Manual/?m...projecttab.htm
[3] http://www.visualbuild.com/Manual/?loggingsample.htm
[4] http://www.visualbuild.com/Manual/?t...mlogaction.htm