Embedding a Git reference at build time

A while ago I posted a tool that updates a [freshly built] binary version information resource and increments build numbers for version identification and tracking.

This time it is a variant of the tool: the utility would check git details for a given repository clone and embed it as a string item of the version information resource. Regardless of version numbers, the “git log -1” text printed into binary resources makes it possible to map the binary to specific source code snapshot in retroactive troubleshooting scenarios.

The embedded information is a text put into named string item in standard VERSIONINFO resource, readable for example by Visual Studio IDE:

More to that, the application itself can read its own resources and use the information to present interactively via GUI, or include the references, such as especially SHA1 hash of respective commit, into produced log files etc.

The application takes two mandatory arguments: path to repository and the binary to patch. The rest of the arguments are optional and customize the process.

Z:\Toolbox>UpdateVersionInfoGit-x64.exe
Syntax: UpdateVersionInfoGit-x64.exe argument [argument...]

Arguments:
 help - displays syntax
 path <path> - path to cloned Git repository directory (mandatory)
 binary <path> - path to binary to be patched with file version update (mandatory)
 git <path> - path to git executable
 pretty <git-log-pretty> - git log pretty parameter string, see https://git-scm.com/docs/pretty-formats (default: format:"%H%n%D%n%ci")
 language <resource-language> - resource language for version information resource (default: 0x0409 LANG_ENGLISH/SUBLANG_ENGLISH_US)
 value <resource-string-name> - version information string name to put git log value with (default: GitLog)
 dump - print version information data block dump before and after update

The utility can be easily integrated into build process as a post-build event:

"$(SolutionDir)_Bin\Third Party\UpdateVersionInfoGit-$(PlatformName).exe" path "$(SolutionDir)\." binary "$(TargetPath)"

Download links

Build Incrementer Add-In for Visual Studio: Latest Visual Studio Versions

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:

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.

Two mouse clicks 7-Zip archives for a developer

I have been frequently troubleshooting remote systems and otherwise provide various temporary binary files to remote production sites with fixes or beta versions of new features etc. The software is such that that customer sites have specific combination of hardware, configuration, hardware on LAN, software conflicts and there is a number of things that are very much easier troubleshooted directly on the production server, through remote connection. Typically I am using TightVNC and Windows Remote Desktop, sometimes LogMeIn, RAdmin and more rare alternatives (among such I would like to specially note TeamViewer).

Obviously except for released versions of binaries (which also exist in several versions from different configuration builds), there appear a number of intermediate files, DLLs and EXEs which are addressed to specific problems and fixes. The problem with multitude of different versions of the same DLL is widely known as DLL hell.

It is not actually a big hell since we are trying to follow simple rules:

  • DLLs should be backward compatible, or if the compatibility is ever broken, DLL version mismatch scenario should be handled as gracefully as possible
  • DLLs and other binaries should have VERSIONINFO resource
  • version information file version’s least significant number is incremented with each and every build; in particular this allows to keep privately program databases (PDB) and immediately find the corresponding database by file version
  • newer binaries should always have greated file version than older ones

The problem however has been that the typical process of building a temporary build of a library and uploading it to remote location required too many clicks. Considering a number of times I have been through these operations, an automation and a productivity tool should have appeared long ago. Finally this is solved by a shell extension that compresses binaries into a transferrable archive in two clicks:

Context Menu Shell Extension

Compression formats of 7-Zip (.7z), 7-ZIP SFX (.exe) and ZIP (.zip) are at user’s choice.

Continue reading →