TestStand deployment: duplicate non-existent DLLs (-19035)

[DavidFCannock]

I'm unfortunately stuck with working with LabVIEW and TestStand again and stumbled upon a pretty interesting set of bugs this time.

I've set up a TestStand deployment to create installers for an automotive test sequence + corresponding LabVIEW library. In most languages, once you've set this up initially it works reliably thereafter, since it's just a case of editing text-based configuration files (directly or via a GUI). It's not much different with TSD files, except that like with every other type of file NI software works with, it's all binary, and NI binary files have a habit of self-corrupting themselves.

I discovered a while ago that LabVIEW lets you separate compiled code from the VI source code, which makes it play nicer with VCS and got rid of some of the grievances I had with the whole thing. However, source-only VIs cannot be executed by the LabVIEW runtime engine, which is what I'd need to use on the deployment machine. To workaround this, NI recommend creating a source distribution of the project files. I did this, specifying the source distribution to be generated under $PROJ_DIR/build/Source and updated my TestStand workspace (.tsw) to reference these VIs. I was able to create an installer and run it successfully on the deployment machine.

However, I made some changes to improve the reliability of the application and I've been trying to repackage them. For some unknown reason, both the "source distribution" build specification and the TestStand deployment have gone haywire. When I try to regenerate the source distribution, it now tries to preserve the VI hierarchy by generating the entire path under my C: drive to the VI under $PROJ_DIR/build/Source. In other words, it will try to generate something like $PROJ_DIR/build/Source/users/<me>/Documents/LabVIEW Projects/My Project/src/Some Library/Some VI.vi instead of just $PROJ_DIR/build/Source/src/Some Library/Some VI.vi as before. This then fails because the generated path of most of the VIs is too long (> 260 characters or so). I'm temporarily working around this by generating the source distribution under C:\Temp instead and stripping out the parts I need.

I've now tried to generate an installer from the TestStand deployment, but it fails with error -19035 because it seems to think there are duplicate DLL files being used by my project, even though one of the paths of the duplicates doesn't exist (it seems to think "Program Files" is under my user directory) and even though this process was working perfectly fine before.



I really don't understand why deploying applications has to be such a song and a dance compared with programs written in other languages. I'll try doing what I usually do when LabVIEW/TestStand screw these things up, which is checking out the last working revision of these binary files and re-attempting the same changes. But if there's a simpler way, I'd be happy to hear.

For what it's worth, I found this thread describing a similar problem and tried deleting my compiled object cache and mass compiling all my project VIs, but this didn't have any effect.

[DavidFCannock]

The two issues seem to be closely related. When I generate my source distribution, the two top-level directories under C:\Temp are "Program Files" and "Users". Through a long chain of sub-directories, the "Users" directory eventually leads to all my project VIs. On the other hand, "Program Files" just leads to a single DLL (the problematic one, lvanlys.dll) located under Program Files/National Instruments/LabVIEW 2017/resource. My guess is that if I can find out why it's trying to include that DLL in the source distribution, it will eliminate that whole chain of nested paths when I generate the source distribution and prevent the "duplicate DLL" error I see during the TestStand deployment build.

(Edit) To clarify, this is what the preview looks like for my source distribution:

[DavidFCannock]

Incredible - I checked out each commit all the way back to when I created the source distribution build spec (and it worked) and the issue persists. I'm versioning every non-generated/non-trivial file under my project directory - source VIs, project files, deployment configurations, etc. and the fact that I still see this problem after resetting my workspace to earlier snapshots means that the issue is external to my actual project. The whole point (or one of them) of using a VCS is for the guarantee that I can always return to a known, working version of my application no matter how badly things get messed up.

It's absolutely irresponsible of the people designing this system to circumvent that and cause all these hidden, unknown changes outside of the project directory that break the development cycle. Something that happened while editing/generating either the source distribution or TestStand deployment must have changed something somewhere on my system (outside of my project directory) to make it think that "lvanlys.dll" is a dependency that has to be included as part of the distribution. What are they expecting us to do? Create multiple system restore points while developing LabVIEW? Develop everything inside a virtual machine? Is the next step to try reformatting my system?

[DavidFCannock]

Okay, I managed to stumble across a very unreliable solution to this problem.

The NI developers (in their infinite wisdom) decided to make it so that using certain things (like the new Channel API) causes compiled code to be generated outside of the project directory under LabVIEW Data/2017(64-bit) (in the case of using LabVIEW 2017 64-bit). I found that if I cleared the compiled object cache, deleted this folder and tried mass-compiling, then occasionally I would be able to generate a source distribution that doesn't include "lvanlys.dll". It was extremely hit-or-miss whether this would actually work (far more miss than hit) so it took about 20-30 attempts of doing this after checking out an old revision before I succeeded. After I created the source distribution, I checked out the latest commit and was able to generate a deployment though that.

I need to test the deployment works on the deployment machine and I guess I need to rinse-and-repeat this procedure if it doesn't.