LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Cannot read Version of Packed Lib correctly

Solved!
Go to solution

Hey guys,

 

in order to optimize our struggle with the distribution of various packed libs to various projects, I would like to implement some kind of solution that tells me for each packed lib, what it's dependencies are and the related versions of them. We use many libraries that rely on additional libs, that also rely on additional libs.

So a lib dependency example could look like this:

Project

->Toolbox library - v1.2.3.4

    -->XML library - v2.3.4.5

    -->Database library - v.3.4.5.6

 

So my idea was, that on every build of a packed lib a pre-build VI is executed, that modifies the library description and adds a list of dependency libs and their versions. At the project for example I can use a VI that reads this list from the library description and allows me to automatically check if every library has all their dependencies at the version the expect. If this is not the case, a warning will tell me what library has a problem.

 

So far for the background. My problem is now, that the lib version is not read correctly. When I read it, I always get Version v1.0.0.0 instead of e.g. v1.2.3.4. When probing my way to the root cause I find, that the wrong version already comes from the LabVIEW property node:

Jenso_0-1741013337773.png

Checking the file itself reveals that the packedlib has the correct fileversion. I also restarted LabVIEW in case of any problems with some old data stored in memory.

 

Is this problem a known issue? Is there a better way to read the lib version?

 

I packed my sandbox project and attached it. Code style is bad, but it should do the trick. Open and execute /dev/testEnv_libVersion.vi to see what I mean.

 

Thanks in advance!

0 Kudos
Message 1 of 8
(395 Views)
Solution
Accepted by topic author Jenso
Message 2 of 8
(369 Views)
Solution
Accepted by topic author Jenso

Your problem is there is a difference between the Library version (version of the lvlib) and the built library version (lvlibp). There is a hidden gem at <vi.lib>\Platform\fileVersionInfo.llb\FileVersionInfo.vi that you can use to get the build version.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 3 of 8
(361 Views)

Ah thanks a lot. That is a working solution. For anybody else looking for a solution here is how I modified my code. This includes both solutions, the solution of UliB and the solution of crossrulz.

 

Jenso_0-1741019111801.png

 

 

I guess I might end up with the LabVIEW internal solution of crossrulz, in order to avoid problems with teststands that might not have .net Framework installed.

 

Thanks again 🙂

0 Kudos
Message 4 of 8
(351 Views)

Don't forget to close the "FileVersionInfo" refnum after the property node when not needed anymore.

Also, the refnum coming from the "App" method is static, so closing it is a no-op:

raphschru_0-1741019478140.png

Regards,

Raphaël.

0 Kudos
Message 5 of 8
(348 Views)

Thanks for the hint! I forgot about that...

0 Kudos
Message 6 of 8
(338 Views)

A bit of maybe unneccessary info.

 

The retrieval of the packed library version through the FileInfoVersion function is only working under Windows since NI does here pack the actual packed library format file into a Windows PE header and adds an according version resource to it. Under all other platforms the packed library format file is left as is (NI calls it LEIF, probably something like Large Executable Interface File or whatever). This file format seems to have no option to store version information (probably the reason they did the wrapping into a PE file format) but this feels like an utter hack. Why fix a problem for a multiplatform file format by simply wrapping the whole into a platform specific format on one of the platforms without thinking about something that supports all platforms?

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 8
(264 Views)

Ok, I see. In my virgin imagination I was thinking that getting a file version of a packed lib is a simple thing... Looks like this is not the case 🙂

0 Kudos
Message 8 of 8
(252 Views)