How to obtain the version of a packed library file programmatically

[zkabitz]

Hello!

I have two major questions today. The first - how do I obtain the version number/information of a packed library, programmatically in labVIEW?

Secondly, how would you find the .dll dependencies of  a packed library if the .dlls are external to the library? I understand that that kind of information isn't exported when the lvlibp is built, but is there any way to find out what .dll/which .dlls it will load into memory BEFORE it actually loads them/calls them?

Ultimately, I hope to combine both of these into a task that will tell you the version information of a packed library, the packed libraries that it calls, and the file versions of the .dll files in both.

Thanks!

[zkabitz]

I figured out how to obtain the version information programmatically. You can use a vi from vi.lib to retrieve the file information - previously I thought that it only worked for .dll and .exe files.

The name of the vi is "FileVersionInfo.vi" and it can be found under (labVIEW version)\vi.lib\Platform\FileVersionInfo.vi

Still need help with the second problem though. I might post it under a different thread.

[paul_cardinale]

Try this.

[zkabitz]

I'm running labVIEW 2012 - is there anyway I can open this?

[paul_cardinale]

Here it is.

[zkabitz]

Thanks, that turned out to be really helpful.

Is the code supposed to completely flatten the block diagram of a referenced VI? Because I think that it may not do just that - in debugging, it seems like a lot of the GObject class names right before the case structure in "Get VIs Called DLLs and Dot NET DLLs.vi" are "SubVI." Most/all of the VIs in my lvlibp that have CallLibrary nodes are subVIs (maybe even subsubVIs), so that might explain why it isn't working very well for me.

I've never worked with OOP before so I apologize if I'm not understanding this correctly.

[WNM]

I was searching the NI website for a list of all possible diagram "class names" when I stumbled across this discussion and it just so happened to do what I was looking to do with the class names. Like zkabitz I was wanting to operate on a VI heirarchy rather than just a single VI but Paul's library for the VI did 95% of the heavy lifting (thank you!) so it was a simple enough matter to add support for subVIs. The attached library makes makes use of (and includes) a two of Paul's subVIs and modifies his top-level VI to include support for checking out subVIs.  I decided it would be more efficient to modify his top level VI to include a case for a "SubVI" objects than it would be to call his unmodified top-level VI from a new VI that would itself have to go through much of the same work to flatten a bunch of block diagrams to pick out all the subvi objects.

[manu_lv]

Hi,

also have a look here. Worked for me. You can also get the file version of the packed library through commandline/powershell.

https://stackoverflow.com/questions/25648155/windows-command-line-to-read-version-info-of-an-executa...