03-30-2020 03:25 AM
@Kevin_Price wrote:
I dug into the "hidden gem" version a little because the pure .NET version shown in msg #4 has a small flaw (arguably) that I've run into before. When both the Patch and Build values are 0 in the executable, the .NET string output truncates them away. So if you built up a version "1.0.0.0" in the build spec, the string output would be "1.0".
The "hidden gem" version appears to me to avoid this flaw as does the visible dev environment code shown in msg #6. Both seem to build up a string from the individual integers for Major,Minor,Patch,Build so there won't be any truncation. My guess is that the "hidden gem" version might support non-Windows platforms where the .NET version wouldn't.
-Kevin P
The .net version also have properties to get Major, Minor, Patch and Compile versions indiviually so you can build the string yourself. 🙂
03-30-2020 09:25 AM
@Yamaeda wrote:
The .net version also have properties to get Major, Minor, Patch and Compile versions indiviually so you can build the string yourself. 🙂
Yeah, that's what we started doing after we got bit by the string-only query. (And this wouldn't be any *real* issue in a lot of cases, but in a regulated industry with documentation calling for software version 1.0.0.0 and software that self-reports only 1.0, well...)
I'm intrigued by the Hidden Gems version but we're pretty much Windows-only so for now, it ain't broke so I won't fix it. 😊
-Kevin P
03-30-2020 01:12 PM
so, here's another option - although, I don't know if this is the default generic conduct:
after you have compiled your .exe via the LabView Application Builder,
open the .exe file with an texteditor,
e.g. Windows Editor,
look at the end of the file,
voila: