Release called class from memory

[D1140]

Yes 

[D1140]

Yes

[Andrey_Dmitriev]

---

@Kyle97330 wrote:

---

@D1140 wrote:

I am Facing crashing issues because of that

---

How exactly does the class just existing in memory cause crashing issues?

DETAILS!

---

In the past, I encountered almost the same issue, but with traditional LLB libraries (this project was started in 2006). Let me explain. I have a relatively large application with a Plug-In architecture. Depending on the features, such an application contains 50–70 plug-ins, and in total, I have over 300 right now. This allows me to build an app much like assembling Lego bricks. Each plug-in is 'compiled' into an old-school 'legacy' LLB library (I have plans to migrate to packed libraries but haven’t done so yet).

Now, the key point: I would like to have the ability to 'upgrade/downgrade' a running application 'on the fly,' without restarting it — simply by replacing a single plug-in on the disk and in memory. This involves closing all references to VIs in the plug-in to be upgraded, then replacing the library of that plug-in with a new version on disk, and finally reloading it dynamically within the app. I’ve managed to get this working for minor 'cosmetic' changes, but if the VIs are significantly altered (e.g., new subVIs added), attempts to reload often result in crashes (exceptions somewhere in the LabVIEW Run-Time). As a result, I reverted to the 'upgrade on whole restart' method, which obviously works reliably (close the entire app → replace the plug-in library on the disk → restart).

With Packed Project Libraries (PPLs) and classes, things could be a bit more complicated. However, we can try. For example, how can we 'reload' a running plug-in in this example: https://forums.ni.com/t5/LabVIEW-Development-Best/Plug-in-Architecture-using-Packed-Project-Librarie...?

The issue is that Get LV Class Default Value.vi will attempt to load the class from disk only if it is not already in memory. So now the question is still active: how can we unload a class from memory to 'force' it to reload from disk?

[D1140]

Yes Exactly. Now I am trying to build each dqmh module to PPL. And not using any Dynamic dispach or any oops concept.  I will build ppl for each DQMH module and that in main.vi I will call the dqmh module using a launcher vi. Is that feasible to do?

[Andrey_Dmitriev]

---

@D1140 wrote:

Yes Exactly. Now I am trying to build each dqmh module to PPL. And not using any Dynamic dispach or any oops concept.  I will build ppl for each DQMH module and that in main.vi I will call the dqmh module using a launcher vi. Is that feasible to do?

---

I think, as a feasibility study, it will be better and easier to get this functionality working first without DQMH, just with a minimal example (from the previous message). Then, once it is working, we can move to DQMH, because the mechanism 'replace in memory on the fly' will be the same, but heavy dependency on DQMH will disturb us a little bit.

[D1140]

I am not able to load PPL from the given example. It shows following error.

[Andrey_Dmitriev]

---

@D1140 wrote:

I am not able to load PPL from the given example. It shows following error.

---

Just recompile everyting in LabVIEW version you have and replace packed libraries. With LabVIEW 2025 it works, I checked this.

[D1140]

Ok will try

[D1140]

Do you have DQMH example for this. I tried the above method its good. But i want dqmh example. And What if the ppl keep loaded in memory and I wont replce it unitill I close program. But I will call that ppl multiple times will that cause any issues ?

[Andrey_Dmitriev]

---

@D1140 wrote:

Do you have DQMH example for this. I tried the above method its good. But i want dqmh example 

---

We can do it, for sure. But did you get "reloaded" changed PlugIn from disk with given example? For me it doesn't work.