Visual C++/SourceSafe Change and Build Tracer

Environment: Visual C++ 6, Visual SourceSafe 6, and Access 2000


I needed to be able to relate SourceSafe file versions with modifications and release builds for VC6 projects. Until now, this has involved the manual use of SourceSafe both directly and through the limited facilities directly available from VC6.

I implemented the Automatic Build Incrementer by Curt Blackmon (Thanks, Curt!) described elsewhere in CodeGuru to move my Build number on automatically on Release builds. I also use SourceSafe Keyword expansion (see various CodeGuru articles for more information) to document file versions.

Bugs and Change Requests are tracked using BugCollector, an excellent product from Nesbitt and Modifications (Changes) logged into a Microsoft Access database. Change records include reference to Bug IDs derived in my case from BugCollector records and the Change records themselves are referenced by labels on modified files when checked into SourceSafe. This way, it is possible to relate BugCollector entries, Change records, and file versions in SourceSafe.

However, all these facilities are isolated, requiring manual operations which are both time consuming and error prone. How can the process be more integrated?


The key to integration seems to be automating SourceSafe and Access database operations from the VC6 build process. No access to the VC6 SourceSafe interface is available directly, so this involves accessing SourceSafe directly from VC6 macros, written in VBScript.

By combining the SourceSafe project Check In and label processes with automatic build number incrementing on Release building, project versions can be identified and re-accessed as required.

A macro available from the VC6 toolbars also supports documenting and checking in of files related to a single modification. Again, file versions can be identified and re-accessed based on defined labels.

Optional Bug/Modification Request IDs are entered manually when changes are committed to SourceSafe. No direct link is made to BugCollector (although this is possible because it is a Microsoft Access-based product) and the IDs could equally be derived from other systems.

An optional Microsoft Access database records changes and Builds as they are made.


As is usual with code examples of this type, you should test them thoroughly before use and use them at your own risk. They work correctly in my development environment, but you assume all risk for their use. I will not assume any liability whatsoever for their failure to work correctly in your environment.

I welcome any comments, suggestions for improvement, problems, and so forth, that may be e-mailed to me. Do note, however, that I am not a VBScript expert and have only implemented code necessary to satisfy my own requirements. The code may well have to be modified to suite individual requirements and environments.


The zip file cited in the Downloads section contains a Visual C macro file (mymacros.dsm) and a Microsoft Access 2000 database files (myproject.mdb). Mymacros.dsm includes three separate callable macros. The routines report to the Macro output window. The database file contains two tables used to record changes and builds.

My apologies for any VB inaccuracies—my VB experience is as little as is required to get scripts like these working! I am sure that improvements and modifications can be suggested by those of us more skilled in this language.

I associate AddSSHeader and SaveChanges with toolbar buttons. The Application_BuildFinish routine is automatically called after the build is finished.

Several assumptions are made about the configuration. If these do not hold for your projects, you may have to modify the code accordingly. Check the lines reported in the VC6 output window (Macro tab). If these lines do not agree with your configuration, you may have to change the code.


This routine is called from other routines whenever necessary. It includes accessing the mssccprj.scc file in the project directory. This file is text readable and gives useful information about the SourceSafe configuration for the project.

The Initialise routine is called as necessary to set up a set of global variables necessary to access both files and SourceSafe correctly for the project.


AddSSHeader is a modified version of the SourceSafe Keyword Expansion Template contributed by Steve Miller. The routine will add a header to each open source file that does not already include one.


SaveChanges requests a Change Number and comment. It then checks each open file into SourceSafe with the associated comment. A record that includes the description and files included is added to the Changes table in the database. The routine includes two optional additions, one to label each file and another to label the entire project. Whether you include the lines depends on whether and how you use labels in your SourceSafe projects.


If a release build is completed with no errors, a series of routines are called in turn. First, the existing build number is retrieved. The project is then checked in and a label that includes the build number is applied. A record that includes the present build number and date is added to the Builds table in the database. Next, the resource file is checked out if necessary and the build number incremented ready for further changes.


Download and unzip the file. Access the dsm file and add or replace the routines in your existing macro files by using the Tools->Macro menu command from VC6.

Rename the database file and place it in your project directory. If the database facility is not required, comment out code in the macros as described in the macro file.

Associate AddSSHeader and SaveChanges to toolbars or keystrokes.

What Else

Modifying the resource file in a VC6 project is still a problem—VC6 re-creates the source file from scratch, so included headers are lost.

It is best if only files related to a change are open when the change is committed to SourceSafe.


Download – 47 Kb

More by Author

Must Read