Labview.exe maintains handle to .NET COM control tlb/dll files after VI has been closed.

[Chilango]

Hi I've developed a com object in VB.NET that I am calling from labivew via the Automation enum and invoke vis.  I am closing the reference after the open vi (I've attached the Vi I created).

the problem is if I run and then close this VI, I can still see that the labview.exe process has handles on the dll,.tlb,.pdb files associated with this control.  I cannot rebuilt this com control without shutting down labview. 

Is there another way to remove these references once I have run the VI.  I really don't want to have to shut down labview every time I want to rebuilt the .NET control.

thanks

[Tunde_A]

Hi,

Try to add the VI to a LabVIEW project and open the VI from the project explorer. After running the VI, you can then close both the VI and LabVIEW project before rebuilding the COM object.

Attached is a LabVIEW project file I created with this VI.

Tunde.

[Chilango]

Hi Tunde,

I actually have this vi in a labview project.  The problem is when I close the vi and the project I cannot rebuild the control without closing down labview.  Using process explorer (systemInternal tool) I can see that the labview.exe has handles to the com .dll/tlb/,pdb files in the directory where my com dll resides.

[rolfk]

---

@Tunde A wrote:

Hi,

Try to add the VI to a LabVIEW project and open the VI from the project explorer. After running the VI, you can then close both the VI and LabVIEW project before rebuilding the COM object.

Attached is a LabVIEW project file I created with this VI.

Tunde.

---

Well, not sure about projects but in pre project times this has been a very common issue with LabVIEW. Using DLLs with the Call Library Node I regularly ran into the situation that I had to shutdown LabVIEW in order to recompile the DLL and use that new one. Closing down the VIs just wasn't enough. It's some time I did serious DLL debugging so I will have to try this with projects sometimes.

A bit annoying but I didn't really do much about it. The strange thing was that it sometimes was not necessary but I couldn't find a consistent pattern.

Rolf Kalbermatter

[Lycangeek]

The main issue for LV is that we do not spawn off another process when running the VI - it is done all in the same process as the IDE. This is very different from other IDE's, such as Visual Studio. This also has impacts on what can be released.

Currently, you are correct - once you load up certain components, they are locked in memory and you must recycle LV to release them. We are always working on ways to remove this restriction, but it is often very compex or out of our hands all together.