[mike_laff]

Hi, thanks for the feedback.

The On Step Failure settings apply to any step that fails, whether in a group or subroutine or not.

--- My point here is that subroutine/group steps (the step itself not the steps within) cannot fail as they do nothing. Therefore, is there any point to these failure step settings? I for one, nievely thinking that the subroutine failure settings would do something if the steps within the subroutine failed, wasted hours trying to use these settings. I think it would be helpful to save others the same trouble.

1) It's more common to do all that from a single step in VBP (a Make VC or Make VS.NET step to set/increment versions, specifying a workspace or solution containing all 20 projects + setup projects)

--- I'm unsure what you mean here. I'm trying to put together a single nightly build (1 .bld file) of around 30 big products.

The first part of my build process builds around 50 shared libraries/components - all the libraries are simple VC/VS builds, all the components use a subroutine to (a) update the version, (b) do a VC/VS Make and (c) update source control with new version. Any faillure in this part stop the build completely.

The second part of my build then builds the products themselves. Each product uses a subroutine to (a) update the version, (b) do a VC/VS Make and (c) update source control with new version. Some subroutines are much more complex. Most products also and have their own independant libraries/components. Here, I want every product to have an opportunity for building.

The third part of my build does the setups. Each setup uses a subroutine to (a) update the version, (b) do a Setup Make and (c) update source control with new version. Again, I want every setup to have an opportunity for building.

2) If broken out into multiple steps for each project, it's still probably more common to stop on any step failure and correct the problem before continuing (later projects will likely depend on the earlier ones, etc.).

--- I see you point, but I would imagine that a fair number of people would have projects similar to mine where we have a number of shared components/libraries (that do require a complete build stop) followed by a number of projects/products that should each have a chance of building in their own right. This can dramatically save time on big projects as you can potentially fix two (or more) problems without having to restart the build twice (or more!). This has been mentioned a few times in these forums in the past.

3) Even when continuing, there probably aren't many steps that could fail and the build should still continue, so

what you could do: in the subroutine, mark the build step to continue on failure, and add an Exit step (configured to exit with a success status) after it with a build rule of

%LASTSTEP_STATUS% does not equal 0

--- This does not work if you run any failure steps in the last step. By the time the Exit step gets to evaluate this status, the last failure step will have already modified the %LASTSTEP_STATUS% back to 0 - well, as long as the last failure step itself succeeded! This is exactly where I've had to add custom code (in every stepdone action) along with using my own status macro to be able to track the real status of the build and not including the failure steps. This is very cumbersome and why my previous suggestion would again save a lot of time and effort.

eg.

sub vbld_StepDone()
Set pmacro = Project.Macros("MYLASTSTEP_STATUS")
pmacro.Value = Step.BuildStatus
end sub

along with an exit step status with a build rule as you describe albeit, using my macro...

%MYLASTSTEP_STATUS% does not equal 0

Note. I actually find it simpler not to use the Exit step as you end up with it after every other step. it's much simpler, in this case, just to skip all subsequent actions using the following build rule on them all:

%MYLASTSTEP_STATUS% is equal to 0