Can we build custom type files into EXE?

[styrum]

I have an additional (custom) project item(file) type defined and a primary project provider for it, complete with its own icon/glyph and a dedicated editor for editing such files. Such files contain just some additional info about the class as a plain XML/JSON text but have a custom file name extension. I manage to store such files within class libraries in the project (.lvclass files are just XML text too) as yet another type of class files (in addition to .lvclass,.ctl,.vi). Just like in the case with class method VIs in classes inheriting from one another, there can exist this new type of files with the same names associated with those related classes (and stored in the same folders with the .lvclass files in the source). The logic of selecting particular ones at runtime is the same as with overriding method VIs: the one in the calling class itself or (if no such file there) the one in/from the nearest ancestor is used.

 

The project providers is a "rusty nails" topic, as we know. For example, for some reason I can't drag those custom items/files between folders/classes. As anyone can see, it is the case for the published examples too, by the way. https://forums.ni.com/t5/LabVIEW-Project-Providers/bd-p/bymqyodmkc?profile.language=en

 

However the project provider issues for my type themselves are not my main concern right now. The question I have for this forum is: can we make the app builder to store such additional items/files with the the other class items (.lvclass, .vi, .ctl) when building an EXE, i.e. inside the EXE itself, in the corresponding class folders, right where they were in the source? By default the app builder throws all of them into the same "data" subfolder. That can create filename conflicts, so the app builder makes additional "data" folders with unpredictable names. I can kind of work around this by having only the top level VI in the EXE and creating source distribution with directory structure preservation for the bulk of the code or use the app builder API to programmatically create/update build specs with known (separate for each class) target folders for storing these files but all that looks too clumsy.

 

Edited December 4, 2020 by styrum

[dadreamer]

Maybe it's not what you are looking into, but did you consider using VI Tags to store, read and write the data? It's contained inside a VI in a dedicated resource section, so it will be inside an EXE after the building as well. It has one disadvantage though - you can't use OS tools to view and edit the data directly, but have to use LabVIEW/RTE to do that. If you're fine with it, then try to give it a go.

https://zone.ni.com/reference/en-XX/help/371361R-01/lvprop/generic_m/

https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-04-13-2009/m-p/888538?profile.language=en

[styrum]

As I suspected, the short answer is: no, we can't. This was confirmed to me by a known expert in LabVIEW application building and deployment Matthias Baudot from Studiobods. Merci beaucoup, Matthias! Here is his answer:

Unfortunately, it is not possible to embed custom files inside the executable when building a LabVIEW application. Only “code” files in the point of view of the LabVIEW Run-Time Engine can go inside the executable. Other “support” files must go in a separate location on disk. Therefore, it is not possible to do what you want.

However, you could configure your exe build specifications to store your classes outside the executable and so maintain the file hierarchy with your custom files residing next to your lvclass file.

For instance, let’s say you have the following LabVIEW Project:

 

 

 

By default, the resulting files when building your executable will be:

 

 

 

Instead you could have something like this:

 

 

 

Here you can see that your Application.exe will now load the classes from the “Classes” folder. Each class resides in his own “Class 1”, “Class 2” or “Parent Class” folder with all the files including your Custom file.

To achieve this, you simply have to create a new Destination (named “Classes” in this example) and make sure to check the “Preserve disk hierarchy”:

 

 

 

Then, configure each class to go to this new destination (“Classes”):

 

 

 

 

Note that even if the the VIs of your class are not embedded inside the executable, you can still protect your code from being pirated by making sure the “Remove block diagram” checkbox is ticked (which is the default behavior). In this case, your code will be machine compiled the same way as if it goes inside the executable and the block diagram will be removed so nobody can see your code when distributed this way:

 

 

 

 

 

I hope this helps… Good luck with the Project Provider Framework 😉!

 

Regards,

 

Matthias Baudot
    Tel : +1 (418) 780 4443
    matthias.baudot@studiobods.com

 

 

 

[styrum]

A nasty caveat with "Preserve disk hierarchy" is that you can end up with too long of a resulting path string for some files in the build which is  still not too long in the source. There is an apparent limit on the path length (in terms of total number of characters including the file name, not number of folders levels) after which LabVIEW (Windows) refuses to open a file with such a "too long" path (this can happen with unzipping a deeply nested archive into a too deep folder of too by the way). The limit can manifest itself even at a build stage (Error 6). But it is worse when it happens while running an exe. So keep your folder and file names short and keep the source code folders as close to the root of the drive as possible. The chances to run into the "too long a path" issue become higher when your source located on one drive references libraries from another drive, say, from user.lib or vi.lib which are obviously within LabVIEW folder which in turn is most likely on drive C while you may want to keep your source code on, say, drive D. Then you can end up with a folder structure MUCH deeper in the build than it is in your source and run into the problem with much higher probability.