Best practice for knowing the link between binaries (*.exe and *.dll) and their source code?

Question

I'm working in a company, where we work with a kind of plug-and-play system:

An executable is put inside a central directory, and there is a Modules directory, where DLL files can be inserted, which will then automatically be used.

The biggest point is: there is no link between the binaries (EXE and DLL files) and their source code, and regularly, I need to update a DLL without even knowing which version of the source has been used in order to compile into that particular DLL.

One of my previous employers has managed getting the GIT short SHA into the file details of the compiled binary, but as my current employer does not work with a build server, and as it seems quite difficult to copy that file details into the Windows clipboard, this seems not to be such a good idea.

So now I'm thinking of some kind of a release.txt file, containing all GIT short SHA for all binaries, but this has the hazard that people might compile on their own PC, copy the binaries onto the customer's system, forgetting about the release.txt file and the whole problem persists.

Is there a best practice for such kind of problem? (It looks to general that I can't believe there's no general solution for this)

I'm working with GIT as a versioning system and Visual Studio as a development tool. Our development is not based on tickets like JIRA or so: everything must start at the versioning tool.

Answer 1

as my current employer does not work with a build server

You should have a build server. Which runs an automated build process.

If you really can't get one, make a "build VM" which sits on a computer somewhere in the office.

the hazard that people might compile on their own PC, copy the binaries onto the customer's system

You should strongly discourage people doing this at all and make them go through the build server.

This is a "process" problem, which needs addressing through people rather than technology.

Answer 2

The general idea is always the same: whenever you create a release of your product, make sure you assign a new unique version number to the end product, and use that version number for tagging the related source code files.

How you accomplish (and ideally automate) this in detail is up to you and your team, and it depends on things like how many "sub-products" you are maintaining in one repo, or how you give them version numbers, or which SCCS you are using. But you can typically solve this with a few scripts in your favorite scripting language.

When you would have a build server, for example, you could add the tag first, and then let the server build the final product from it, compiling the version number from the tag into the final EXE and DLLs files. When you don't use a build server, you may have a "release build script", which grabs the version number from the source and uses this for tagging, after it run a successful build. The script might also check for duplicate tags/version numbers before running the build, or ask the user to enter a new increased version number. It should also collect all the necessary files for deployment in a "deploy" folder, and package everything in a way the delivery to the customer becomes as simple as possible.

but this has the hazard that people might compile on their own PC, copy the binaries onto the customer's system, forgetting about the release.txt file

Using the release build script should reduce the manual effort for exactly this step, then people will use it for pure laziness.

There are several variants of this possible, just tailor it for your needs.

Answer 3

As stated by pjc50, a build server is the solution, and I just realised how:

Every file has a checksum, and when the file gets copied from one computer to the other, the checksum stays the same. So the checksum can be used for identifying the compiled executable.

So, the build server should contain a table, containing all compilation actions which have been done, containing at least following fields:

• Executable name
• Corresponding project (Visual Studio solution/project)
• GIT commit hash
• Executable checksum
• build datetime
• Name of the person, who asked for the build
• (other?)

It might be useful to keep the build logging somewhere (in case one needs to analyse build hints/warnings/...)

This answer might not be complete. If anybody thinks of information, which needs to be added, feel free to write a comment or to edit the answer.

The whole idea behind this approach is that, like this, there is a stone hard relation between the executable, as present on a customer's system, and the version of the source code (in the commit hash). That information will be kept on a central build server, well protected by my company.

Answer 4

Other answers say that you should have a build server. I don't disagree with that, but you absolutely don't need a build server to automatically add the commit hash to the assembly info. Add a new target to your MSBuild file for each project to run BeforeBuild, and have that target call a script that gets the current commit identifier. It can then generate a source file with the appropriate attributes to set the file version to the commit identifier.

The generated file will depend on what language your DLLs are built from, but if they are C# it should look like this:

// This file is Auto-Generated

using System.Reflection;
using System;

[assembly: AssemblyDescription(<your-commit-identifier-here>)

Then include that file in the compilation step, and you will be able to see the source commit by right-clicking, viewing the files Properties->Details.

This relies on everyone using the same project files to build the code, but the builds don't need to be run on a common server. You can also put other information into the assembly info if needed.