.NET Reference doesn't load automatically from LabVIEW VI

[eric.atherton]

I'm using a LabVIEW VI within TestStand that uses a .NET call to a custom DLL that I have built.  When I load the VI in LabVIEW, the VI works as needed.  When I load the same VI within a TestStand step, the .NET reference doesn't load automatically.  When I right-click on the .NET reference, I need to browse to the DLL.

Has anyone else seen this problem?  Is there an option that I'm missing within TestStand to automatically load DLL's?

[dug9000 · Accepted solution]

This is likely due to the way LabVIEW and the .NET framework load assemblies and the location of your assembly. LabVIEW will find the assembly a different way when you are using a LabVIEW project then when you are not (i.e. when calling it from TestStand). Are you using a LabVIEW project when running from LabVIEW? If so, you might want to try the TestStand 2010 beta if you can as there is now support for LabVIEW projects: http://forums.ni.com/t5/NI-TestStand/Announcing-the-TestStand-2010-Beta-Program/td-p/1136621

Other alternatives for having LabVIEW find your assembly:

1) Don't use a project in LabVIEW and see if you can specify the assembly by path. Likely it will work when called from TestStand as long as the path is exactly the same.

2) Put your assembly in the GAC

3) Put your assembly in the application base path (i.e. the directory of the .exe file that's running TestStand).

4) There might be other solutions, you might try posting to the LabVIEW forum to see if a LabVIEW expert knows of a better way.

Hope this helps,

-Doug

[eric.atherton]

Doug,

Thanks for the response.  I did find that when I use a LabVIEW Project, the assembly is found.  When I open the VI without the project, the assembly is NOT found, and the VI is broken, just like TestStand.

I think I will try the TestStand 2010 Beta, since we will surely upgrade to 2010 after it is realeased, I'm assuming @ NI Week.

Thanks again!
Eric

[DRock]

Hi Eric -

It is not safe to assume that NI TestStand 2010 will release on or around NIWeek.
It is fairly safe to assume that NI TestStand 2010 will release before the end of the year.

Unfortunately, I cannot disclose a specific target date for the release of NI TestStand 2010, as we cannot publicly disclose this information.  I hope you find the Beta informative and powerful - we would highly value your feedback!

[Terry Mac]

I’ve seen the same problem and the fix for me is that you put the .Net component in the same directory as the vi panel is running from (or being developed in).

I have another similar problem with using .Net components forms and showing it from a Vi panel. It works OK the FIRST TIME I run the panel. If I stop the panel and re-start it again and show the .Net component again it is not initialise correctly and none of the controls on the .Net component show (all static stuff on the .Net form show but the controls don’t)

To fix this I have to exit Vi completely (including the getting started form) load the vi panel and it will work the first time I run the panel again. Its as if the .Net component is not being re-created correctly when the Vi panel is re-started.

[eric.atherton]

So I found a solution that I like while allowing my .NET structure to be anywhere I like.  Just put the path of the sturcture into the Windows Environment Variables for PATH, and you are all set.  Put it at the beginning of the search, and this will work every time.

[dug9000]

---

@Terry Mac wrote:

I’ve seen the same problem and the fix for me is that you put the .Net component in the same directory as the vi panel is running from (or being developed in).

I have another similar problem with using .Net components forms and showing it from a Vi panel. It works OK the FIRST TIME I run the panel. If I stop the panel and re-start it again and show the .Net component again it is not initialise correctly and none of the controls on the .Net component show (all static stuff on the .Net form show but the controls don’t)

To fix this I have to exit Vi completely (including the getting started form) load the vi panel and it will work the first time I run the panel again. Its as if the .Net component is not being re-created correctly when the Vi panel is re-started.

---

Terry, are you using .NET controls in the LabVIEW .NET container? Or are you referring to a .NET Form that your VI is causing to be displaying by calling into .NET code?

Do you have a simple VI and/or other code you can attach to this thread which illustrates the problem, perhaps with a standard .NET control so you can avoid having to send us your specific .NET code?

Thanks for any details which might help us reproduce and debug this.

-Doug

[Terry Mac]

What I’ve found is that if I use the “Close Reference” component all is OK.

The “Abort Execution” must be stopping execution without disposing of the .Net component.

I’ve added a STOP button to the Vi panel and as part of this I close the reference to the component, I did try linking to the Close Panel event but this did not have the same result. Is there an event I can link to, that runs on an Abort and Close panel event?

[dug9000]

There is potentially an issue with .NET UI controls in a LabVIEW .NET container when called from TestStand. Please let us know if this is your use case.

Thanks,

-Doug

[Terry Mac]

“TestStand” I guess this is how I’m using it at the moment, eventually we will need to compile the Vi panels to a stand alone component (and include the .Net assemblies). Are you saying that this should not be a problem when we do this?

So should I expect other problems? This problem seem to be related to the re-creation of the .Net assembly when it has already been created once. I was expecting that creating a new instance of an assembly would do just that but it looks as if you need to use a “Close Reference” explicitly to force the .Net functionality to clean up before creating a new instance of the assembly.