how to add to llb file version

[Matan-inZiv]

hi

i would like to add to the llb files created via labview some kind of version control and the best way is setting the file version that can be seen in the explorer. how can i accomplish that ?

[GerdW]

Hi Matan,

---

@Matan-inZiv wrote:

i would like to add to the llb files created via labview some kind of version control

---

Generic recommendation: DON'T use LLB files anymore!

Use separate VI files and organize them in lvlibs instead…

[Matan-inZiv]

thanks for the recommendation

still i have code that has LLB and would like to  have some kind of file version is there any way to to this ?

[GerdW]

Hi Matan,

---

@Matan-inZiv wrote:

still i have code that has LLB and would like to  have some kind of file version is there any way to to this ?

---

LLBs basically are just a very simple kind of archive format to hold several VIs. The main use point was to circumvent the 8.3 filename limitation of ancient Windows/DOS versions. NI doesn't recommend them since years/decades, they also converted the LLBs found in vi.lib into subfolders.

They don't offer any "version" handling on it's own.

When you start to talk about "file version": you are using a SCC tool (Source Code Control) like SVN or GIT to keep your code in a database holding current AND previous versions? When your answer is "No." then my recommendation is: start IMMEDIATELY to use such a tool!

[rolfk]

---

@Matan-inZiv wrote:

thanks for the recommendation

still i have code that has LLB and would like to  have some kind of file version is there any way to to this ?

---

I really would like to know what version information in Explorer you refer to! Windows does not know about LLB files so Explorer can't show any LabVIEW specific version information even if it would be in an LLB. But the only available version number is about in what LabVIEW version the individual VIs inside of it were saved in. LLBs themselves do not have any version meta data.

In addition the LLB shell extension available in LabVIEW 7.x has long been discontinued by NI and therefore Explorer could not learn about LLBs and the files inside of them unless you use a LabVIEW 7.x or maybe 8.0 version on your system.

[tst]

I agree with Gerd that using SCC is the way to go for handling versioning (or even just sync/backup). Git is popular today, but can be hard to understand. SVN with TortoiseSVN is relatively easy to setup and use. It's better if you have a dedicated server for this (with its own separate backup), but you could also do everything on a single computer.

As Gerd alluded to, you can also convert the LLBs into folders, which will convert each VI to a separate file, which makes many things simpler. If you give the folder the full name of the LLB, then the path to the VI doesn't change and all the code which loads the VIs will keep working correctly (e.g. for c:\x\y.llb\z.vi it doesn't matter if y.llb is a file or a folder).

Rolf, I'm guessing that the version number is something like what you can have with EXEs and DLLs, but I don't know if Windows lets you set arbitrary metadata like this for each file type, or whether you're limited to what Windows allows for each file type.

I suppose it would be possible to add a VI to the LLB which has a fixed name and the "version" of the LLB in an indicator on the FP or in the description field or a persistent tag on the VI or something similar, but that would require something very specific for how this works, both for setting the version number and for reading it. I suppose there are cases where this might be useful, but I expect SCC to be more relevant for most cases.

[rolfk]

---

@tst wrote:

Rolf, I'm guessing that the version number is something like what you can have with EXEs and DLLs, but I don't know if Windows lets you set arbitrary metadata like this for each file type, or whether you're limited to what Windows allows for each file type.

Nope. That Version information is from a specific version resource in the PE (portable executable file format) that EXE and DLLs are stored in. And Explorer can detect when a file is a PE file and then shows you the additional "Details" tab in the file property dialog and the according version in the version resource, if it is present.

Other file types can add their own shell extension handler (a COM DLL) that Explorer then will invoke for file types that that extension was registered for. For instance this is how MP3 files get their audio specific information items into that tab.

The old NI file extension for LLBs was a bit different. It did not really provide additional property handler information to Explorer but instead provided to Explorer a file content enumeration handler so that Explorer can present the files inside the LLB as if it was just another hierarchy level in the file system.

The only thing I can imagine that the OP may mean, could be the Previous Version tab in the Property Dialog. But that is an entirely different thing and provided by the Windows system for files that are managed through File History together with Restore Points. That's however no version history really, more a sort of build in backup system.

I suppose it would be possible to add a VI to the LLB which has a fixed name and the "version" of the LLB in an indicator on the FP or in the description field or a persistent tag on the VI or something similar, but that would require something very specific for how this works, both for setting the version number and for reading it. I suppose there are cases where this might be useful, but I expect SCC to be more relevant for most cases.

---

I have done that for several frameworks but with PPLs. All of them contain a MetaData.vi in the root "folder" and there are build steps that can be included in the build step as Pre-Build step that populates the front panel elements with the version and copyright information from the project. Then there is a support library that is part of the framework to query this information given a path to a lvlib or lvlibp file.