Identifying an executable's version

[cgibson]

Hi, I have a hypothetical problem.

Can I identify which version of my source code was used to make an executable? In other programming languages this is trivial. The compiler can be relied on to make the same file every time. So you build the file, run an MD5 checksum and compare that to the deployed file. In LabVIEW the executable is NOT guaranteed to be the same. So how do you tell? Why is this important? Well lets say an employee left the company. Before leaving, he deployed a version of software as a beta. The beta test is now over and it is time to update the repository. Which version of code did he use? It might be the one on his old laptop, or the one he checked into the repo, or you might not have it anymore. How can you tell definitively?

Of course the brute force way is to scrap the beta, create a new beta, complete a new test etc...

What we do now is put a version number string in the code which we can access in a couple of ways. This is obviously error prone and may not have been updated properly. Also a version I have in the repo may have this number and still not be the code the executable was compiled from.

Is there a way to check? Some kind of fingerprint I can generate?

[Mike_King]

There is no way that I know of to guarantee a fingerprint will match a specific code version. You can certainly do a hash of the file or hash of source content and store that relationship, but as you said, rebuilding from the same source code does not produce the same resulting exe. However, best practise is to use versioning from within the build specification, so each build from your code is incremented, then your source code can be linked to this by tag or date or version branch itself, to keep the relationship.  The version info is in the exe that way, and you can see it from the file properties.  If you have an automated build process, you can have it increment and save this in your project on any build from continuous integration, that way you know and can go back to an exact source code point in time that matches the build you need to support.

[altenbach]

For a hypothetical problem, it would also be nice to know the hypothetical LabVIEW version. 🙂

For the recent versions, NI invested in some efforts to ensure that identical builds result in binary identical executables, but there are probably still exceptions.

[Mike_King]

which recent versions are you refering to??   LV 2015 at least still has this problem.

[Hooovahh]

The method I use for this is to embed the commit version of our SCC to any builds that are made.  Then if you look at the EXE it will have a version like 1.2.3.93 where in this case 93 refers to the commit number and rolling the source code back to log 93 means that source will be what the EXE was made from.  To help with setting this build number automatically I use a Pre-Build VI which gets ran before the EXE is made, which sets this to whatever the SVN log it currently at.

http://forums.ni.com/t5/LabVIEW/Pre-Build-EXE-and-Installer-Set-Version/td-p/3149028

A similar technique could be used for any SCC.  Several other techniques could be used to with the Pre-Build.  Like you could have a comment in the about of your application that gets updated when building, which embeds a CRC or MD5 of the source used.

[altenbach]

---

@Mike_King wrote:

which recent versions are you refering to??   LV 2015 at least still has this problem.

---

Sorry, my memory is apparently no longer what it never was. Here is some indication that it was investigated but there are hurdles.

Https://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-built-applications-should-be-identical/idi-p/...

(Sorry, posting by phone)

[cgibson]

Hypothetically it was LabVIEW 2009.