CRC changes with each build of some projects. Why?

[jamesbe]

Good afternoon good fellows,

I have run into a predicament. The company I work for builds VIs often, and for some time has been using the IEEE method for determining the 32-bit CRC for our applications to ensure people are running the correct VI. Unfortunately, I have been having a hard time wrapping my head around why some VIs produce consistent CRCs while others don't from the build process.

Do I have the wrong idea about the purpose of CRCs? My thinking was that if you build a project twice and don't change anything, the CRC should be the same. I am not personally changing anything, and am not sure if LabVIEW is for some reason saving things, even when they haven't been changed, so what could be causing this issue? Note: I have disabled Auto incrementing of the version number.

This is a major roadblock to productivity so any advice would be greatly appreciated.

Thank you

James

[CoastalMaineBird]

Do I have the wrong idea about the purpose of CRCs?

--- No.

Does the size of the EXE change from one build to the next?

You say some VIs produce consistent CRCs and others don't.  Do you mean some EXEs?

Anything in common about the ones that do NOT stay consistent?

If you build it FIVE times, do you get

(  ) Five DIFFERENT CRC values?

(  ) 4+1

(  ) 3+2

[jamesbe]

Thank you for the response CoastalMaineBird,

Yes I meant EXE. I have checked every setting in the build properties and tried matching the settings of the ones that have consistant CRCs to the ones that don't to no avail.

The EXEs are all the same size, and the CRC's are all different.

[CoastalMaineBird]

Just to be perfectly clear:

You're saying that if you build the SAME exe from the SAME project five different times, you will get five DIFFERENT CRC values on the EXE?

If so, then I have to think that some automatic date-stamping is getting in your way.

Again, can you find anything in common among all the EXEs that are inconsistent?

Is there any PREBUILD or POSTBUILD VI being used?

[jamesbe]

Yes, I right click on the Build Specification and select Build. Afterwords I move the file to a new folder and repeat the process so I have five identical files with the same names.

In one project the automatic versioning was enabled, and disabling it then provided the same CRC. Other than that one project, I have been unable to find anything different in the project settings between any projects. 

Time-stamps are the only thing I can think of that could be causing the issue, but I haven't the slightest idea how to prevent that. One would think there would be an option hidden somewhere.

There are no pre-post or post-build VIs.

[CoastalMaineBird]

OK, unless you can run a file-comparison tool on the EXEs and see what exactly has changed, I'm out of ideas.

If they're all the same size, it must be a version number or timestamp.

Pick a BUILD that does this.... does it use any DLLs?

Does it use any PPLs (*.lvlibp)?

Does it incorporate any inon-LabVIEW files (*.txt, *.pdf.... etc.)?

Anything in the ALWAYS INCLUDE section?

[crossrulz]

---

@jamesbe wrote:

Time-stamps are the only thing I can think of that could be causing the issue

---

And I can tell you from experience that that is what is happening.  Most other languages also have a timestamp buried somewhere in the executable when it is built.  What we resigned to doing is do a binary comparison and verify is was within 5% or something like that.

[Bob_Schor]

How do you store/save your LabVIEW Source files?

We use a Version Control System, Tortoise Subversion (hereafter called TSVN) to manage and "control" Version information.  In particular, each Project (which can result in multiple Executables, for example, Data Acquisition, Configuration File management, specific Analysis routines, and specific "Support" code) can have multiple Executables built from it.

In TSVN, each Commit creates a new Revision Number that uniquely identifies the Source code from which the Executable is built.  We use this Revision Number to populate the "Build" part of the four-element Version Number maintained in the Build Specification within the Project.  The other three parts, Major, Minor, and Patch/Fix, we set ourselves in the Software (i.e. we have a "Global Constant" called "Version" that might be "2.1.0".

As part of the Build Process, we use a Pre-Build Action to query TSVN for the Revision Number of the Project (which, as already noted, is maintained on TSVN, hence has a unique Revision Number) and set this as the fourth element of the LabVIEW Version Number (giving us something like 2.1.0.4321).  When the Program executes, it queries its Version Number and displays it as an Indicator on the Front Panel.

There is one catch -- when you do a Build and execute code as part of a Pre-Build Action, if this code involves setting the Version Number of the Build, this setting takes place after the Build Number has been cached and used as part of the Build Process.  That is, this "Pre-Build" Action is preceded by a "Really-the-first-Action-before-the-Build, Caching the Version Number".  [I've complained about this, and have proposed an Idea Exchange to fix this here, but am not very hopeful].  There is a work-around -- build twice.  Here's how it works:

• Assume the Project has a Version Number of 2.1.0.4321.  You modify it, commit it back to the Repository (whereupon it becomes Revision 4324), and are ready to Build.
• You Build.  The Pre-Build Action runs, finds that the Revision is 4324, and saves that in the Build Spec.  However, the Build Process has already "remembered" the original Version as 2.1.0.4321, so that is the number that gets "built-in" to the Build, and that would be displayed if you ran the Program and executed the Get Version Specification function.
• You immediately Build a second time.  Again, the Pre-Build Action runs, finds that the Revision is (still) 4324, and saves it (again) in the Build Spec.  But now it has the "Pre-Pre-Build" value of 4324 to use when it does the Build, so now the Program is built with the appropriate Version of 2.1.0.4324.

Note that this method ties the "Version" of the Executable to the LabVIEW code saved in Subversion.  In principle, if we saved the code as LabVIEW 2014, checked it out, and built it with LabVIEW 2014, and LabVIEW 2015, it would identify itself exactly the same way, and should functionally execute the same, though I would expect the binaries to be different.  But if a bug occurs, the User can say "Hey, there's a bug in 2.1.0.4324", and I can respond "Why aren't you using the current release, 2.1.0.5235?  We found and fixed that bug six months ago!".

[tst]

More details here - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/LabVIEW-built-applications-should-be-identical/idi-p/1...

Note a) the comments and b) the small number of votes for the idea, indicating not many people who saw the idea were motivated enough to vote for it, indicating this is probably a relatively rare need (which obviously exists, but isn't relevant to most people).

[jamesbe]

CoastalMaineBird, all of our VIs use the same DLL, none that I've seen use PPLs, and some do incorporate docs or spreadsheets. The ones that do have a consistant CRC do not use docs or spreadsheets, but other VIs that do not use them either produce different CRCs. Nothing in the ALWAYS INCLUDE section. 

crossrulz, I did a comparison using FC.exe that comes with Windows 7, and the files seem to be very different, even though they do the same thing, and are the same size. Do you have a suggestion to compare two binary files graphically, that does not require installation or administrative privileges? 

Bob_Schor, I save them to either my desktop or a server where others can access them. We also use Subversion, but it is more manual that the way you do it since we only have another and myself developing. I can attest that I love subversion though.

tst, Do you know how people have been making sure files haven't been modified?

I noticed that although the executables change, the CRCs of the source files don't. We may need to transition from using the CRCs of the programs to the CRCs of all the files involved, which would be much more tedious because of a silly oversight by NI.