Need advice on Application build - The Myriad of Class Files

[PaulOfElora]

Can I ask for some newbie advice on how to structure folders for an application build?  Yep, I need to set up relative paths for config files and such, I get that.  But what about *.lvclass files, and all those pesky identically named class method vi's? I'm guessing that I'll need to build an installer, not just an application, because I'm guessing there'll need to be a folder structure that allows for all those same-named vi's, right?

Also, how do VI Server strictly typed vi's work with the build process?  Specifically, I have some asynchronous-run vi's.  In the development environment, we create strictly typed references by navigating to their vi files.  But what happens when the builder encounters those vi references?

As you can tell, I'm a newb when it comes to building applications of any sophistication, so I'd sure appreciate any tips - thanks, and stay healthy! paul

[srikrishnaNF · Accepted solution]

Hi PaulOfElora,

This can achieved in may ways at the application level itself.For that you need to know certain things such run-time environment and relative paths.

One important thing is the source files referenced by the source file in any application.exe will be <path to application.exe>\SourceFile.vi .You can refer this link "https://www.ni.com/docs/en-US/bundle/labview/page/referencing-source-files-in-stand-alone-applicatio..." for more understanding of relative paths.

Same logic is applied to all class files and corresponding methods.As per the best practices,you need to save the individual classes and its methods in seperate folders  and those can be referenced again like i mentioned above.

[tst]

To add to the stuff in the previous reply:

1. The basic idea is that you don't need to do anything. The EXE is basically a zipped folder where all the VIs are stored in exactly the same hierarchy and you get that automatically.
2. If you want the folder of the EXE, the Application Directory VI can help.
3. Generally, don't have hard coded paths.
4. Note that for config files, today you are generally expected not to place modifiable files in the program files folder and the folders there are generally locked, so your program can't write to those files. You can use the Get System Directory VI to get the path to a relevant folder, like the appdata folder, and then you should probably handle creating the config files if they don't exist or adding them when installing.
5. If you do decide to place the config files in program files, you should probably configure the installer to unlock the relevant folder/files, so that it can be modified.
6. Besides building an EXE, you should build an installer, which can install the LV runtime and relevant drivers and place files in the correct places (for example in the program files folder, in the appdata folder, shortcuts, etc.).
7. For launching VIs dynamically, the question isn't about the type of the VI, but about how you identify the VI when you open the reference to the VI.
   
   If you use a static reference to the VI and then use a property node from that to get the VI name/path for the Open VI Reference function, then you're fine - LV handles static reference correctly when building an EXE. It will include the VI in the EXE with all its dependencies and will know where to find it.
   
   If you're building the path dynamically, then it depends on whether there is something static which causes the VI to be in memory. If there is, it will be included. If not, you need to add it or a VI calling it to the always included section in the EXE build settings.
   
   My suggestion would be to use the first method, unless you're working with something like a plugin architecture, which has some different considerations.

[crossrulz]

---

@tst wrote:

unless you're working with something like a plugin architecture, which has some different considerations.

---

At which point we need to start talking about separate project files, building libraries into Packed Project Libraries (PPLs), and properly distributing said PPLs for your main application development as well as deployment.  It has a steep learning curve, but very useful once you get over that hump.

[PaulOfElora]

Fantastic, thanks so much guys!  I really couldn't do this work without all your kind help - paul