This post really contains two different questions/issues. The first question is about using auto-populating folders with .lvclass files. The second is a more specific question about why I think I need to use auto-populating folders for some .lvclass files in a project. I understand that .lvclass files should not be put into auto-populating. Even though I know that is a rule, I don't really understand why. I think the reasoning is that the auto-populating folder ends up making a copy of the .lvclass file, and this could cause dependency issues since I now have two copies of the .lvclass file in memory, is that correct? I have run into a situation where it seems that need to put some classes into an auto-populating folder so they can be distributed with my EXE by an installer. My EXE will load those classes into the program via a factory at runtime. Besides putting those .lvclass files into an auto-populating folder, I can’t find any other way to distribute the .lvclass files with my exe. Am I stuck with putting these classes into an auto-populating folder or is there another way to have my installer include them for distribution?

LabVIEW

auto-populating folders and .lvclass files

Author

@tst wrote:

I'm not aware of anything like that. I certainly don't see how it would relate to DD VIs. What I did want to add in my last reply (and probably forgot) is that auto-pop. doesn't make much sense in libraries - libraries define membership strictly, so you have to explicitly add the VI to the library (and it presumably can't be both in the library and in the auto-pop. folder at the same time, but that's just a guess. Maybe that's the issue he was talking about). In short, if you have a library (and a class is a library), you don't need auto-pop., because all the VIs in the library appear in the project.

Your explanation of why auto-pop and libraries makes a lot of sense, and it also helps me better understand Aristos Queue's response on this thread. I think you are right that the apps engineer might have been refering to the fact that the file can't be in both the auto-pop folder and the library (class) at the same time, so a "copy" is made somewhere, somehow.