If you share concept (as I do) that every build should have a unique file version stamp in it, for a simple purpose – at least – to distinguish between different version of the same binary, then a helpful tool of automatic incrementing fourth number in FILEVERSION’s file version is something you cannot live without. After going through several fixes and updates, it is finally here available for download.
The last issue was in particular that projects that are in solution’s folder are not found by the add-in with Visual Studio 2008. Why? OnBuildProjConfigBegin event provides you with a unique project name string in Project argument, but it appears that it is only good enough as a quick lookup argument with Visual Studio 2010.
// EnvDTE::_dispBuildEvents STDMETHOD(OnBuildBegin)(_EnvDTE_vsBuildScope Scope, _EnvDTE_vsBuildAction Action) throw() STDMETHOD(OnBuildDone)(_EnvDTE_vsBuildScope Scope, _EnvDTE_vsBuildAction Action) throw() STDMETHOD(OnBuildProjConfigBegin)(BSTR Project, BSTR ProjectConfig, BSTR Platform, BSTR SolutionConfig) throw() { _Z4(atlTraceCOM, 4, _T("Project \"%s\", ProjectConfig \"%s\", Platform \"%s\", SolutionConfig \"%s\"\n"), CString(Project), CString(ProjectConfig), CString(Platform), CString(SolutionConfig)); _ATLTRY { // NOTE: const CString& cast forces compiler to process statement as variable definition rather than function forward declaration CProjectConfiguration ProjectConfiguration((const CString&) CString(Project), CString(ProjectConfig), CString(Platform), CString(SolutionConfig)); CRoCriticalSectionLock DataLock(m_DataCriticalSection); // NOTE: Check the project on the first run only (to skip multiple increments in batch build mode) if(!Project || m_VersionMap.Lookup(ProjectConfiguration)) return S_FALSE; _Z3(atlTraceGeneral, 3, _T("Checking project \"%s\"...\n"), CString(Project)); // Checking the project is of C++ kind CComPtr<EnvDTE::Project> pProject = GetProject(CComVariant(Project)); _A(pProject); ...
When the project is in a folder, Projects::Item can just fail if you are looking up for the element interface. In which case, you have to walk the collection taking into account SubProjects and additionally look there yourself. Visual Studio 2010 is one step smarter and gives the thing to you right from the start.
Eventually, the add-in is here. It’s job is to go to .RC file and increment file version each time you build the binary. It reports the action into build output window:
To install the add-in:
- download and register (regsvr32, administrator) the VisualStudioBuildIncrementerAddIn.dll
- apply one or more Visual Studio integration registry files:
Or, alternatively, use installation file VisualStudioBuildIncrementerAddInSetup.msi (version 1.0.4, 379K) to have it done for you in a user-friendly way. Partial source code, a Visual Studio 2010 projectis also there in repository.
Still good for Visual Studio 2012, needs just a registry update: Visual Studio 2012 Registration.reg.
Hi. Is there a way to increment product version along with the file verison?
Quite possibly yes, I will look into this.
Thanks, it would be great.
I have also another suggestion. In my opinion, it’s better to increment file version post-build, instead of pre-build, beacause it’s get incremented even when build failed.
The idea was that once build is complete – the source code and the binary have all matching numbers. Your approach makes sense too, so this might be an option either-either. I don’t even think it’s any difficult to do, but I did not yet have time to check it out, sorry.