common version number

[dawson]

Hello,
I want to version at the solution level, but my solution contains 2 projects. For example, if the solution contains 2 projects and one of them changes, then I want to update the version number on both projects (so they are the same). However, if neither of the project changes, I don't want to update the version numbers. How would you recommend accomplishing this?

Also, if I am doing a nightly build process, does Visual Build actually build my solutions / projects each night? I noticed when I build a solution the first time it builds the projects, but then when I build it again the projects don't get compiled. How does Visual Build know that nothing has changed before it checks the files in VSS?

Thanks for your help,
Dawson

[kinook]

There's nothing built in that can do that for you. In your VBP project, you would need to capture the timestamp of the projects' executables before the build, build the solution, compare the timestamps with the original timestamps, and if either one has changed, update the version of each project to the desired value and build again.

As to your second question, it depends on what type of incremental build capabilities VS.NET provides (I'll assume you're using VS.NET for builds since you indicated that you are using a solution) for the language you're developing in (VBP ultimately invokes the VS.NET command-line compiler to perform the actual build).

For VC++ projects, the VS.NET command-line compiler provides incremental build intelligence to (usually) only build when some source file has changed. For other .NET languages, we've found that the 'incremental build' option in VS.NET is really a misnomer. C# and VB.NET projects have an incremental build option, but even if checked, once a solution is closed and reopened after building, even if no changes were made, it will always rebuild the project (or at least regenerate the executable) when built again. I haven't seen any explanation from MS regarding this. Apparently the idea is that the compiler is so fast it doesn't matter (although it still causes problems for auto-increment version logic).

[dawson]

How would I go about capturing the timestamp of the projects executables before the build? What if I don't have access to these executables, ie. they are just built from the source-code and deployed to other machines?

I was wondering if I could do it with the VSS Diff function? For example, before compiling the projects, I would check VSS to see if there is any difference between the current files and the ones in the previous label. If there is then I would compile and version increment all projects, if not I would skip that step. Do you think this would be possible / viable?

Also, with regard to my second question from before, I didn't explain it very well. I wasn't wondering about the actual compile process, but the build process in your product. It seems like the first time I run "Build", it will build everything great, but then if I run "Build" again, all my steps are skipped! How does it know to skip these steps? How can it decide to skip stuff before it even checks VSS files? Is there any way I can turn this behaviour off?

Thanks for you time,
Dawson

[kinook]

If the executables from the prior build existed, you could use the FileSystemObject (see vbld_FSO in the help index for details) to retrieve their last modification time and store them in temporary macros.

If the build box will not have the executables from a prior build (which it sounds like is the case), or if they will be re-created with each build anyway (i.e., you're building C# or VB.NET projects), then their timestamps won't be helpful. You would need to perform a diff on each source file of each project to determine if anything has changed since the last build.

Neither way is trivial to implement or maintain. You may want consider alternatives. For instance, when we build VBP, we have a major product version (i.e., 5.0, 5.1, etc.) that we keep in the ProductVersion of the main exe project and show on the About dialog. We use the auto-increment logic to increment the FileVersion of each project when built (i.e. 5.0.0.1 -> 5.0.0.2) so that each individual component version changes whenever that project's executable is built.

As far as build vs. rebuild in VBP, if a project is opened and built in the GUI and it completes building, building again won't do anything because all steps are marked completed. Rebuild will reset the build status of all steps and start the build over again. By default, the build status is not saved with the project file, so all steps will always be built from an automated build, since the build will occur in a new instance of VBP. The topic 'build -> Building Projects' in the help index goes into more detail on how it all works.

[dawson]

I will consider revising our version numbering schema, however, in the meantime, I have one more question that should get me rolling.

If I do a recursive diff, how do i perform conditional logic based on whether there is a difference or not? Does the diff function store a boolean yes / no anywhere? Not sure how to do this.

Thanks again,
Dawson

[kinook]

That depends on what source control system you're using. If you're using SourceSafe, its ss.exe command-line tool (which the VBP SourceSafe action wraps) outputs a report of the differences between the versions specified. In the following step, you would need to parse the output (available in the %LASTSTEP_OUTPUT% macro), probably using a Run Script step, to determine if the output contains changes or not. You would need to compare the output of a no-diff and diff run to determine if there is a reliable comparison that can be made, and then implement logic to perform the comparison.