Project macro problem

[pmcclosk]

Hi all,

Our build uses a perl script to get the latest code changelist number and creates a file named with this value. This works fine. The next step is a process files step that gets the changelist number file name. When we attempt to set a project macro named BUILD_NUM, it's getting lost. The set build num step is also not producing any output. We use this same sequence and configuration of steps in 2 other product builds, they are working great. This particular build is done in VBP 5.0. The others are done in 5.7. The above steps were working perfectly until approx. 2 weeks ago. Any ideas?

Thanks

[kinook]

If it has been working and then stopped working, it sounds like something changed in your build process. I would compare with the 2 builds that are still working or peruse the changes made to the build scripts and/or build machine configuration in the last 2 weeks.

[pmcclosk]

Thanks for the reply. I checked this against the two other builds, and they are all the same. This build file is also in source control and has not been modified since 1/20 of this year. I did notice that the problem began in the build for March 1st. The file versions now end in a 3 digit number where our 5 digit build number used to be. The 3 digit number is also incrementing, but with no apparent pattern. My next step is to talk to the application developers and see if anything has changed in the version resource files.

[pmcclosk]

I've tried a few things since posting this. The problem seems to be in the StampVer.exe tool that came with VBP. The build sets the correct changelist number, today's being 65540. In the output for the StampVer step, the build number is 1004. Here is the command for this step:

%TOOLSDIR%\StampVer "%SOURCE%\our_executable.exe" -p"%VERSION_NUM%.%BUILD_NUM%" -f"%VERSION_NUM%.%BUILD_NUM%"

When hovering over this, the %BUILD_NUM% macro displays 65540, the correct value. The step output is still showing 1004, and that's what the file is ultimately stamped with. A lot of our processes DEPEND on accurate file versioning. This all began on March 1st, is there a known bug in the StampVer.exe? This product is using VBP 5.0. We're too close to release for this particular product to put time into upgrading to a newer version of VBP on this particular machine.

[pmcclosk]

Let me apologize for the posting above, I've inherited this build and I am constantly finding out information about it. The StampVer.exe shows a different company in the version info. I'll try contacting them.

[kinook]

We don't make StampVer and it's not part of VBP. But it looks like a 2-byte unsigned integer (65535) limit in that product.

[pmcclosk]

Sorry about the mixup, I found out who the maker of StampVer was after posting. Thanks for input on this even though it's not your product causing the problem, I think that shows a lot about your company and its level of customer support.