NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

.NET DLL reference in LabVIEW packed library used in TestStand

Solved!
Go to solution

I am using a inhouse developed .NET dell to communicate with some hardware. I am calling it from LabVIEW using .NET constructor nodes, and the LabVIEW VIs is called from Teststand. That works fine until I deploy it, then it either says the VIs are broken (if I use Teststand deployment utillity to make packed Libary), or it can't load after deploy (if I am not packing it to packed libary)

 

I have found out the solution might be, that I make a LabVIEW packed Library around the .dll where I can call al the functions, that can deploy and also run, if i place the .DLL in the Windows GAC. But optimal I would like to have the dll in same location as the LabVIEW project, so it is easier to update together. 

And the solution I have now is not very stable. 

 

How do you organize it?

Anders Pedersen Sekanina
sekanina.dk




0 Kudos
Message 1 of 9
(320 Views)

Working with .net assemblies can be a challenge 😉

 

If you (like me) are NOT using the GAC, you need to make sure, that the relative path between the VIs and the DLL always stay the same. I guess you will need to configure this on the deployment utility as well.

 

When using PPLs referring to DLL, the same more or less applies.

 

My strategy is to have a folder for each library, in this context a DLL is also a lib

 

Oli_Wachno_0-1724820365978.png

The LabVIEW lib "knows": I always have to go one directoy up and look for the dll-directory (naming scheme has to be in place)

This way, I can also use the same dll from differnt libs, which is a use case for me.

This folder structure has to be maintained strictly during development and deplyoment

 

I have seen people using a common directory liek C:\My Libraries where thy put in all there stuff. Can be done as well.

 

0 Kudos
Message 2 of 9
(289 Views)

Hi Oli 

 

Thank you for the answer, I am quite sure it was also how I was trying to do it, and it does also work fine before I deploy Teststand. 

 

So it is probably more experience with how to set up Teststand Deployment Utillity with DLLs used in LabVIEW, that is the question for me. 

 

But I will definitely look at the C:\My Libraries solution.

 

Thanks again

 

Anders

Anders Pedersen Sekanina
sekanina.dk




0 Kudos
Message 3 of 9
(280 Views)

Hi again

 

I have tried Oli's suggestions, but it has not brought me any further.

 

It turned out the solution with adding it to Windows GAC was not a a stable solution. 

 

I am using a .NET constructor .dll to control some hardware. It is working fine in development mode, but when I try to deploy Teststand, I get following error:

AndersSekanina_0-1725259711927.png

My LabVIEW deployment settings are:

AndersSekanina_1-1725259752045.png

 

I have tried:

  • Calling the DLL directly from the LabVIEW project used in Teststand, .dll located in folder near the calling VI.
  • Build a lvlibp with all calls to the .dll. Packed libary and dll located in folder close to the calling Vis.
  • Place the .dll and .lvlibp in c:\Addons.
  • Place the .dll and .lvlibp in c:\Addons.. and add a lvaddoninfo.json, and add addon directory to labview.ini file

 

I do always get same issue, and I can’t find more debug info, because the Vis are not broken when I open them in LabVIEW.

Anybody with a suggestion?

Anders Pedersen Sekanina
sekanina.dk




0 Kudos
Message 5 of 9
(232 Views)

Looking at the screeshot.... does the folder name just accidentally contain the String OneDrive or is this actually mapped to a sharepoint?

 

0 Kudos
Message 6 of 9
(225 Views)

Yes you are right;)

 

I just made a small test project in documents, where I can share screenshot etc, så it has no influence on the issue.

 

The real project is under c:\Repositories\...

 

Regards Anders 

Anders Pedersen Sekanina
sekanina.dk




0 Kudos
Message 7 of 9
(220 Views)

Sounds strange.... 

We are using a PPL based HAL (which also call DLLs)... 

 

I guess this has someting to do with how "close" your deployment folder structure to your development folder structure.

We try to keep it as close as possible...

 

Probably doesn't help you ...

0 Kudos
Message 8 of 9
(203 Views)
Solution
Accepted by topic author AndersSekanina

It turned out to be a LabVIEW bug 2645388 in 2024Q1, an upgrade to 2024Q3 solved the problem.

 

Kudos to NI support.

Anders Pedersen Sekanina
sekanina.dk




Message 9 of 9
(157 Views)