Project explorer seems to be confusing VIs and .NET DLLs

[hwilterdink]

Getting some behavior and warnings I've never seen from a LabVIEW project at my company (names redacted to protect the innocent). We are using LabVIEW 2017 SP1 32-bit.

Upon loading a high-level project that references some shared low-level code libraries managed on our work server, I get warnings that seem to suggest that LabVIEW is getting confused on what is a VI and what is a .NET DLL, for example: The .NET assembly expected to be at "...\Compute Perspective Transformation.vi" was loaded from "...\Emgu.CV.dll". See attachments for more examples.

After going through the battery of warning dialogs, the project compiles (no broken run arrows), but it also shows the same exact warnings if I close LabVIEW and re-open, so I am clearly not resolving the underlying issue. I have also tried opening the VIs that LabVIEW seems to be confused about, fixing any errors/warnings it gives me, and re-saving them, but this has also not fixed the behavior.

This is a new behavior for a project that has existed for some time without issue. I am also not seeing this behavior on a different high-level project, despite that fact that it references the same shared low-level code libraries.

Anyone seen this before or have suggestions? I'm used to sometimes getting cryptic LabVIEW Project load warnings and having to debug them, but this one is throwing me for a loop because of LabVIEW's apparent confusion on what it's loading as a VI vs. a .NET DLL. Thanks in advance.

[billko]

Actually, the errors appear to be inside VIs that call .NET assembles and you have some crosslinking issues going on. It appears that Emgu CV has quite a few issues with LabVIEW.

[hwilterdink]

Thanks for your observation.

The confusing part for me is that Emgu CV appears to have quite a few issues with LabVIEW in this specific project and at this specific time. We have been using Emgu CV for a few years just fine, and this particular issue just showed up for me in the last week or so.

So I am trying to track down what exactly changed, but have had no luck yet.

[Kyle97330]

The error messages might be confusing but I think I can suggest something that might be a way to make them stop.

When you load a LabVIEW project file, it will look in all the directory and all subdirectories of the folder that the project file is in, trying to load files.  This can occasionally be helpful but can also occasionally be the opposite of helpful.

Looking at the PNG you posted, I can see that it shows that it's been loading files from under the "builds" folder.  Having a folder named "builds" usually means it's been generated by creating a build specification of some kind and having it build to the default destination folder.

This implies to me that there's a good chance you're loading a project and instead of loading DLLs from their original location, it's finding the DLLs that were included in the build spec because the EXE or LVLIBP, or source distribution, or whatever made a copy of them in the build folder that it is now attempting to use.

If this is the case, I recommend you create a directory specifically to store your ".lvproj" file(s) and not put any other files in that directory and not add any subdirectories either, and see if that still gives you messages like this when you load.

[hwilterdink · Accepted solution]

Thanks Bill for pointing out the cross-linking, and Kyle for your troubleshooting suggestions. After much digging I think we resolved our issue, and it did indeed stem from VI cross-linking. I'm not sure if the way we got things cross-linked is overly specific to our setup, but I'll explain it here anyway in case it's useful to a wider audience.

We host our code on our shared office server. The code includes both high-level applications and low-level shared libraries, which call each other as shown roughly in the image below. Here's the key detail: our IT is setup so that some of our office computers are mapped to this server (i.e. an S: drive that shows up in Windows Explorer) and some aren't. Any computers that aren't mapped will access the server by its "raw" name/address (i.e. \\svr01).

I don't know exactly how Windows resolves file paths in such a case, but from LabVIEW's perspective, it seems that loading S:\shared.lvlib is distinct from loading \\svr01\shared.lvlib (despite the fact that, to me, they are the same file). Somewhere along the line, we must've linked a part of our low-level code to both S:\shared.lvlib:x.vi and \\svr01\shared.lvlib:y.vi. This made the high-level code try to load shared.lvlib from both server locations, which then created cross-linking conflicts because of the identical library name.

Apparently, the LabVIEW Project Manager's cross-linking confusion was so great that it told us it was loading .NET DLLs in place of VIs, which was both untrue and a distraction from the actual root cause. Long story short, to fix things we:

1. Closed LabVIEW on all office computers
2. Deleted the contents of our shared libraries' distributable build folders
3. Opened our shared libraries and re-built their distributable code into the empty folders
4. Opened our application libraries and waded through the barrage of Resolve Load Conflicts popups, carefully clicking Load With Selected so that we were only referencing either the S: path or \\svr01 path (not both)
5. Saved everything