NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

TestStand does not load .NET DLL from absolute path

Solved!
Go to solution

Hi all,

 

I am developing a TestStand program using a .NET DLL for UUT communication. When testing the .NET DLL I noticed that the DLL does not work when called from a network share. Since all our test programs are deployed to a network share, the first steps of the ProcessSetup sequence copy the DLL from the deployed test program on the network share to an absolute path on the C:\ drive. Copying the DLL file works.

 

In my test program I adjusted all the steps using the DLL with the absolute path to the DLL on the C:\ drive. Using the sequence editor, this works perfectly. When I deploy the test and run it on another computer, I get the error message:

 

Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

 

If I open the deployed *.seq file, the paths to the DLL are all absolute as set in the sequence editor. When I search for the DLL using ProcExp, I see that the DLL from the network share is used. Why is the absolute path neglected? How can I force TestStand to use the absolute path?

 

A topic I found via the error message proposed to recompile the DLL with a strong name. Doing this results in the same error message.

 

Using TestStand version 4.1

 

Thanks in advance,

Stef

0 Kudos
Message 1 of 5
(4,598 Views)

Without looking into your attached sequence file:

Are you using multiple .NET based DLLs from the network shared directory?

 

I ASSUME the following:

You use multiple DLLs which have internal dependencies. When you load/execute the sequence, one of these DLLs is loaded first and loads, as it looks for its dependencies, the other DLLs from the same path as it was loaded itself. As TS gets to the DLL in question, the .NET adapter checks if the DLL is already loaded. If it is, it simply uses that version.

Strong name include the version number in the DLL. But as i assume that the version on the network shared directory is the same as the one you put locally, strong names do not help to "selectable loading".

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 5
(4,591 Views)

Hi Norbert,

 

I use only one .NET DLL which has only references to .NET Framework DLL mscoree.DLL.

 

0 Kudos
Message 3 of 5
(4,587 Views)
Solution
Accepted by topic author svh

If an assembly is already loaded, regardless of whether it was loaded from the specified location, the .NET framework will use the existing, already loaded assembly rather than the one you specify. Most likely you have already loaded the assembly from the network path somewhere else in your sequences before attempting to load it from the local path. Keep in mind this could be from a process model, or different sequence file.

 

Hope this helps,

-Doug

Message 4 of 5
(4,558 Views)

Once again my sloppy work has cost me a lot of time debugging a simple mistake. Searching for all steps using the DLL revealed one step which was not marked as "load dynamically" and had no absolute path to the DLL. This resulted in loading the DLL from the search directories at startup of the test. Adjusting this step solved my problem. Thanks for helping solve this problem.

 

Stef

0 Kudos
Message 5 of 5
(4,544 Views)