LabVIEW RTE does not find lvpalettesupport.dll

[CsabaF]

We have been working on an update on our test system. The system is based on a measurement engine developed by an external partner company, and we create custom TS test types using their API. The VIs used by these test types are compiled into packed libraries - for example among others a test step configuration VI. We use LV/TS2017.

Recently a small update was needed in the measurement engine, but at the same time we noticed that its API was changed to a packed library (previously we had individual VIs). First the API was delivered in LV2014, but we asked them to recompile in LV2017. 

The updated 2017 API and new function have been tested on our development stations, compiled and sent to the factory. However, the engineers have reported a strange issue, the updated custom test type´s step configuration window can´t be loaded at all when the TS adapter is set to LV RTE. 

The error message is attached, it complains about missing lvpalettesupport.dll. This dll is located right next to the updated API in the TS/Components folder. However, this dll is used by our functions as well, and we copy it to another location when compiling our packed libraries. I believe that the root cause might be somewhere in the packed libraries trying to access dlls with the same name from multiple locations, but I can´t figure out what exactly is happening. It is tricky to debug, since it works on our development stations with LV development environment, even if I change the adapter to RTE. If only RTE is installed, TS will not find the dll.

I tried mass compile our code, renaming the dll in the build specification, cleaning up the virtual machine used for testing to only have one copy of the dll, but nothing solved the issue.

The really interesting thing is, that if I try to open the step configuration VI again, the VI will open, and the engineers can run the test sequence afterwards. This process of opening the configuration VI twice before execution need to be repeated after a TS restart or a complete module unload.

Can someone please give me some new ideas?

Thanks

[iradovanovic]

Can you confirm the LV RTE is the 2017 version the code was recompiled in? 

Thanks, 

Ivana 

[CsabaF · Accepted solution]

Yes, it is the same version as the development environment. 

In the meanwhile we found a working setup - the API was recompiled and the dll was renamed to a custom name in their build specification. The problem disappeared afterwards.

We still not fully understand the root cause, but it has something to do with the nested libraries and how those libraries were loaded by TestStand.