06-28-2017 03:16 AM
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
Solved! Go to Solution.
06-28-2017 03:32 AM
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".
06-28-2017 03:38 AM
Hi Norbert,
I use only one .NET DLL which has only references to .NET Framework DLL mscoree.DLL.
06-28-2017 08:34 AM
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
06-29-2017 03:04 AM
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