Missing dll Files that aren't missing

[SDuffyLV]

Hi Guys,

Numbers [1] to [5] are to reference location in picture attached.

Within the LHM-LINX.lib[1], the "Renci.SshNet.dll" file (and others) was missing[2].

I found that this was because in the LINX folder that the LinxResources was zipped[3], so it couldn't see the dll file. That's fine, unzip the folder[4], put the file in the Resource folder[5] as stated from [2]. 

After removing and re-adding LHM-LINX.lib, this still doesn't recognise that I've put the dll file in the correct location.

I'm guessing there's some sort of disassociation with the file and lib. Is there a way to re-associate the file?

[cbutcher]

This is one of those annoying suggestions like "have you turned it off and on again?", but, have you tried closing and reopening your project and/or LabVIEW environment?

Often quitting out to the splash screen is sufficient in cases similar to this for me, but I've heard that some things aren't always cleared by that and restarting LabVIEW is more clean/thorough.

As a next suggestion, the path looks quite odd - you have a nested vi.lib inside vi.lib - is it possible the code was extracted to the wrong location?

Whether that would cause a problem probably depends on how the library is linked, but it might be expected to be in one of LabVIEW's search paths (or a relative path from there) and it now has a different relative path than intended.

See LabVIEW Shared Library Directories Used by Call Library Function Node for some details if that's the case.

[SDuffyLV]

1) Unfortunately, completely restarting LV2017 (32-bit) doesn't work. It appears that there is a problem with the .lvlib itself where it isn't associating the file I placed into the folder it suggested with the file it should be pointing to.

Is there a way to edit the .lvlib to associate this file?

It's strange because LHM-LINX.lvlib is commonly used for Arduino projects, yet this issue has occurred.

2) For the nested library, I agree that it is odd. This is what the default was when loading the library without any editing.

[cbutcher]

What I meant with the second bit was that perhaps you should have <vi.lib>/MakerHub/LINX/LMH-LINX.lvlib (as you already have) and then next to/under it, <vi.lib>/MakerHub/LINX/Resources/Renci.SshNet.dll.

The nested vi.lib with same name child directories makes me think it's confused about the path.

You can try editing the lvlib file (a sizeable fraction is just XML) but be careful, and work on a copy (because you might hose it).

Edit: if the DLL isn't in the library, it probably won't be in the lvlib text. Dependencies aren't listed.

[SDuffyLV]

For the nested library, I agree that it is odd. This is what the default was when loading the library without any editing.

With editing the lvlib, is it as simple as deleting the .dll and adding it into the items menu from the correct path? This seems to work but not sure of the consequences of doing it this way (e.g. association with other vi's in the lvlib relying on the bad dll and not recognising the good dll just because it has the same name in a different location)

[cbutcher · Accepted solution]

If you load the DLL into your project (for example using the Add > File... Right click menu) then in memory items (e.g VIs in the library) will update, then you can save all.

Be careful if you're using source code control and other PCs have the DLL in a different location - there's a good chance of repeatedly loading from a different directory on every switch in that case (so it would be worth checking the installation process and directory structure).

But if not, you might be ok just saving them all with a new path.

[SDuffyLV]

This has removed the dll file from the Missing list. I'll mark this as the solution.

However, one other question. There are several repeats of this file in folders I don't recognise whatsoever "c:\users\samkristoff\...".

Also, when I press "Go To" they do not link me to anywhere at all.

Do you know what the situation could be here?

Edit: This doesn't seem to have any impact on building the Application.exe without Enable Debugging (the reason why this question was made in the first place) but would still be good to know to clean up the project properly.

[rolfk]

Sam Kristoff was the developer creating and working on the Linx library. As such it is a safe bet that some VIs still hold a path to the original location of the code structure. It should not happen, except:

LabVIEW recompiling is not occurring on conditional compiled diagram sections if they are not active for the current configuration, but things like dependencies still often are somehow seeping into the dependency overview. But because they are disabled they are not considered an error even when they do not exist. It's mostly a cosmetic bug, not perfect and neat but also not a problem usually.

The Linx library supports many hardware targets, whose specific code is often put behind conditional compile structures to allow it to load on the different hardware platforms without causing errors on others. To clean that up you would really have to create all the according targets in your project, load the code into each of them, do a recompile and save it again. Cumbersome and a lot of work to do.

[SDuffyLV]

Thanks a ton for the info rolfk! You've saved me getting myself into a rabbit hole!