TestStand won't load LabVIEW DLL

[RayFoulk]

Hi, All.  I have a project that combines a LabVIEW-created DLL in with my TestStand sequence, and both the sequence and the LabVIEW DLL make calls into a third DLL written in CVI.  This project works great on my development machine & I can debug through all the code normally, but when deployed to the test station TestStand either fails to load the LabVIEW DLL completely or it loads it but with the consequence that the LabVIEW DLL loads and calls a redundant incorrect instance of the third DLL resulting in uninitialized variables and incorrect behavior.  Both machines have TestStand 4.2.1 + Patch 236982, Labview 2010 SP1, and LabWindows/CVI 2010.  All Search Directory configurations for TestStand & LabVIEW are identical between the machines, as well as Adapter settings and the entire project itself.  I have tried replacing the call to the LabVIEW DLL directly with the VI itself, but then LabVIEW loads the wrong CVI DLL itself and I am faced with the same problem.  I try to point the search directories at the whole project tree and enable "Search Subdirectories" and ensure that there is one and only one instance of each library, but then we're back to the original problem and the DLL fails to load with no warning or error: it just skips over the Step as if it had executed OK.  The DLL is compiled with debugging enabled, but when I try to "Debug Application or Shared Library" it reports "No VIs to download from application, connection closed."  On the development machine this works great and I can debug normally.  What I need and what I expect is to load, run, and debug one instance of each library, all under the top level TestStand sequence.  Does anyone have any tips or insight as to what might be happening?  Thank you very much.

[RayFarmer]

So why dont you remove all instances of the third DLL on your system to ensure you get the correct one loaded?

[RayFoulk]

That was done as described, but under those circumstances the top level LabVIEW DLL would fail to load entirely, even when all dependecies were in the configured search path for both LabVIEW and TestStand.

I did some further testing over the weekend and found a workable solution: If the sequence is changed to directly call the VI using the LabVIEW adapter rather than the DLL itself _AND_ the adapter is configured to use the Run-Time 2010 SP1 (which is what's installed) rather than the default 7.1.1 then-and-only-then does it load successfully.  This is not the best solution as it prevents the software from being separated into modular components, but at least it allows me to debug.  I'm thinking the installation must be corrupted somehow & still hoping for a more permanent fix.

Thanks for your help.

[RayFoulk · Accepted solution]

The solution has been found!  Firstly: it was discovered the development station does also have LabVIEW 8.6.1 installed in addition to everything previously mentioned, so that was different -- and likely the cause of the problem even though I never used it.  The TestStand problem persisted on the deployment station, however: with LabVIEW seeming to act normally even after recompiling all DLLs from scratch, but TestStand would not load them correctly under any circumstance.  Until, that is, a forced recompile of the entire VI hierarchy was done using ctrl-shift-run on the top level VI, and then recompile all DLLs following that.  Now everything works as expected.  It seems there were some 8.6 VIs hiding in the project somewhere that the TestStand LabVIEW Adapter was not happy with.