Introduction

This add-in enhances the add-in provided by Mihai Filimon. Instead of incrementing the Private Build number every time a compilation is performed, the product and file version fields in the resource are incremented.

I wanted my code updates to be included as part of his original posting but I have not heard anything back from Mihai, so I am submitting a new article, allowing you to have access to the code and a pre-built DLL, so you don't have to waste your time contacting me.

Background

To read the original article upon which this is based, please see Mihai Filimon's 'Increment Private Build Number' in the MFC / C++ >> Macros and Add-ins >> DevStudio Add-ins section.

Having read the various comments on the previous article, I felt compelled to improve Mihai's (already excellent) code.

I was not willing to put up with DevStudio message about the resource file needing to be reloaded, as pointed out by Brian Shifrin, and added support so that it will look in the rc2 file (in the res directory) first for the VERSIONINFO block(s). If it doesn't find the version stuff there, it looks in the rc file as normal. This allows you to move the VERSIONINFO stuff to the rc2 file to avoid the annoying pop-ups. But for those who can't be bothered, the increment will still work on the rc file. In fact, I would advise moving the entire VERSION_INFO block to the rc2 file to save yourself the heartache of being prompted to reload the resources every time you compile.

The biggest change though is as a result of the comment made by Laurence Zaysser who said that the PrivateBuild and SpecialBuild fields are meant for comment text. So instead, the increment takes place on the last digit of the FileVersion and ProductVersion fields. I have noticed some funny behavior if the numbers do not match for the file version and product version fields. The increment just does not seem to take place. But this should not be a problem if you have never edited the version number manually. If you have, just ensure that the numbers are all the same, and of course separated with commas.

Using the code

In the ZIP file, I have included a Release build of the DLL which can be put straight into the \Program Files\Microsoft Visual Studio\Common\MSDev98\AddIns\ directory. You should then be able to choose Tools->Options->Add-ins and Macros, from your Visual Studio menu, and select the IncVersion Developer Studio Add-in.

Share

About the Author

Ok, it's about time I updated this profile. I still live near 'Beastly' Eastleigh in Hampshire, England. However I have recently been granted a permamant migration visa to Australia - so if you're a potential employer from down under and like the look of me, please get in touch.Still married - just, still with just a son and daughter. But they are now 8 and 7 resp and when together they have the energy of a nuclear bomb.I worked at Teleca UK for over 8.5 years (but have now moved to TikitTFB) and have done loads of different things. Heavily involved with MFC, SQL, C#, The latest is ASP.NET with C# and Javascript. Moving away from Trolltech Qt3 and 4.Jordan.

I have an enhancement suggestion. Have you looked into the macro function that is automatically called before each build? It's called Application_BeforeBuildStart and I was wondering if your app could be called from here. That way, everytime the developer does a build, the number rolls up.

I got this idea from another article that at the moment I can't find (codeproject seems very unresponsive this morning). It was written on 7/11/00 by Curt Blackmon and updated by Valery A. Boronin on 10/10/01. They do the same sort of thing but with a VB script macro add-in.

I installed the addin but it is not working at all for me. When I compile my project in VC6 the version number is not being changed and the toolbar button does nothing at all. Any ideas? Does the resource file have to be in the executable? I have it in a .lib that is built in its own project in the same workspace as the executable and the resource.h file is shared between the two.

I must admit I had not tried this in a dll (which I suspect you mean).

I've just tested it on one of my own dll's and it does work.A couple of things to check are that the name of the dll is the same as the name of the .rc file (or .rc2 - whichever contains the version info)..e.g if your dll\lib is called MyExtraStuff.dll, then there must be a MyExtraStuff.rc2 in the res directory, and MyExtraStuff.rc in the source directory.

Plus, you should ensure that the file version and product version field contents are exactly the same.

[Looking at the code and refreshing my memory of how I coded it, it seems that the rc2 file is checked first. If the file can't be opened (because the filename is not the same as the dll name), then the add-in exits - without going on to check the .rc file.This means that you must have a .rc2 file, and it and the .rc file must have the same name as the dll.]

If you'd like me to improve things, so that it is not necessary for the dll name to match the rc2 and rc name, let me know.Another improvement would be to have the add-in try to open rc2. If this fails it should not exit, but should go on to try the rc file.

I think I know what your problem may be, and it sounds like someone else has also spotted it [budde87].This add-in only increments versions of the currently active project, and if your lib is built as part of a dependency setting, then its version does not get auto-updated.I'm looking into making it do not only the active project, but all dependent projects that get built beforehand.