auto-populating folders and .lvclass files

[zenthoef]

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?

[crossrulz]

Sounds like you are trying to make a plugin architecture.  If that is the case, I recommend looking into Packed Project Libraries (PPLs).

[zenthoef]

That is what I am trying to do. I did consider using a PPL, but I have a couple of concerns about that.

I should have mentioned I am trying to distribute and redistribute the plugins without recompiling my project. I didn't pursue using a PPL because, I think, I would have to recompile my code each time I distributed a new PPL. Is that assumption correct?

Will the factory be able to load the objects from the packed project library? If so, I don't understand how to do this. How would I make my factory go into the PPL and load the .lvclass files I need?

[crossrulz]

---

zenthoef wrote: I didn't pursue using a PPL because, I think, I would have to recompile my code each time I distributed a new PPL. Is that assumption correct?

---

Only the PPL gets compiled and then you can distribute that PPL to be used in other projects.  And since they are already compiled, that will not affect the build of your projects (other than adding them to your installer).

[zenthoef]

If I go down the PPL route, then I lose the plugin ability of the OOP factory, right? If I have a project that uses the PPL distribution, and I change the PPL distribution, do I have to recompile my entire project into a new EXE? 

I am trying to avoid building my entire project into a new EXE (and testing the entire thing) by using a lvoop factory to dynamically load the code at runtime. That way my EXE stays the same and only the objects' methods or data change.

[tst]

If you're looking into building a plugin system, you should look up some materials on that (for instance "lvoop plugins"). This does have various points for consideration (things such as shared dependencies, the fact that PPLs can only be run by the same version they were compiled in, etc.), but I don't have any practical experience with it myself, so I can't comment from that angle.

What I will say, though, is that it seems you have a bad misunderstanding of auto-populating folders. First, there is no "should". You may or may not use auto-pop. for anything you want. I usually prefer not to. Others like to use them for everything.

The second thing is that auto-pop. only affects what goes in the project tree. It doesn't create copies on disk or in memory. It's simply an organizational tool for the project. One place where it can be useful for people who don't usually use it is indeed when you want to automatically include files in a build, but I don't think that really applies with plugins, since presumably you want to build each plugin separately.

[crossrulz]

---

@zenthoef wrote:

If I go down the PPL route, then I lose the plugin ability of the OOP factory, right? If I have a project that uses the PPL distribution, and I change the PPL distribution, do I have to recompile my entire project into a new EXE?

---

No.  You PPL still allow for your OOP factory.  If you change something significant in the OOP heirarchy in a PPL, you may have to rebuild your EXE.  But bug fixes that do no affect API will not cause you to rebuild your EXE.

I highly recommend you give this article a really good read over: Plug-in Architecture using Packed Project Libraries (lvlibp)

[zenthoef]

---

@tst wrote:

What I will say, though, is that it seems you have a bad misunderstanding of auto-populating folders. First, there is no "should". You may or may not use auto-pop. for anything you want. I usually prefer not to. Others like to use them for everything.

The second thing is that auto-pop. only affects what goes in the project tree. It doesn't create copies on disk or in memory. It's simply an organizational tool for the project. One place where it can be useful for people who don't usually use it is indeed when you want to automatically include files in a build, but I don't think that really applies with plugins, since presumably you want to build each plugin separately.

---

From what I've been told by multiple sources is that you can use autopop folders with .lvclass files, but it is not best practice. In other words, you can do it, but should not. It was three years ago I took NI's LVOOP course where I was first told that this was not a good pracetice and that it has something to do with dynamically dispatching objects, but I can't remmeber the exact reason(s).

I turned to both this forum and called NI apps engineers to find out why it is not a best practice to use autopop folders with .lvclass files. After some research the apps engineer over at NI that was helping me concluded that including .lvclass files in an autopopulating folder is not best practice because (according to him) doing so somehow creates two copies of the files in memory. I'm still not totaly sure if that true or not, but unless something changed, there are good reasons why one shouldn't mix autopop folders and .lvclass files. I'd just like to understand what those reasons are. 

[zenthoef]

---

crossrulz wrote:

No.  You PPL still allow for your OOP factory.  If you change something significant in the OOP heirarchy in a PPL, you may have to rebuild your EXE.  But bug fixes that do no affect API will not cause you to rebuild your EXE.

I highly recommend you give this article a really good read over: Plug-in Architecture using Packed Project Libraries (lvlibp)

---

That sounds more reasonable than what I am trying to do. I'll give it a try with my test projects this morning.

[tst]

---

@zenthoef wrote:

From what I've been told by multiple sources is that you can use autopop folders with .lvclass files, but it is not best practice. In other words, you can do it, but should not. It was three years ago I took NI's LVOOP course where I was first told that this was not a good pracetice and that it has something to do with dynamically dispatching objects, but I can't remmeber the exact reason(s).

I turned to both this forum and called NI apps engineers to find out why it is not a best practice to use autopop folders with .lvclass files. After some research the apps engineer over at NI that was helping me concluded that including .lvclass files in an autopopulating folder is not best practice because (according to him) doing so somehow creates two copies of the files in memory. I'm still not totaly sure if that true or not, but unless something changed, there are good reasons why one shouldn't mix autopop folders and .lvclass files. I'd just like to understand what those reasons are. 

---

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.