BuildSpec - Wrong Bitness

[paul_cardinale]

Using LabVIEW 2019, 32-bit,

I created a new buildspec in my (very large) project; it won't run because it can't find

C:\Program Files (x86)\National Instruments\LabVIEW 2019\vi.lib\UDC\win64\niceiplib.dll.

Of course it shouldn't be looking there, the file is really in ...\UDC\win32\niceoplib.dll.

And, as always, selecting "Why is this item in Dependencies?" causes LabVIEW to crash (all versions).

What could case a dependency to the wrong bitness-version of a file?

(For what it's worth, my .lvproj file is attached.)

[wiebe@CARYA]

AFAIK, LV should search all of the vi.lib.

If it can't find a file, it will report the last location where it was found (after a saved).

So if the VI using the dll was last saved in 64 bit, the 64 bit path is reported as last location.

If both paths are in vi.lib, I'd expect big problems. It might look in the last location, and it will find the wrong dll (as they have the same name).

---

@paul_cardinale wrote:

And, as always, selecting "Why is this item in Dependencies?" causes LabVIEW to crash (all versions).

---

It never crashes for me. And I do use it.

[Frozen]

---

wiebe@CARYA wrote:

---

@paul_cardinale wrote:

And, as always, selecting "Why is this item in Dependencies?" causes LabVIEW to crash (all versions).

---

It never crashes for me. And I do use it.

---

Just tested the "Why is this item in Dependencies" for both a DLL and some random vis and it does not crash LV for me either. (LV 2020 atm)

[paul_cardinale]

---

wiebe@CARYA wrote:

AFAIK, LV should search all of the vi.lib.

If it can't find a file, it will report the last location where it was found (after a saved).

So if the VI using the dll was last saved in 64 bit, the 64 bit path is reported as last location.

If both paths are in vi.lib, I'd expect big problems. It might look in the last location, and it will find the wrong dll (as they have the same name).

---

@paul_cardinale wrote:

And, as always, selecting "Why is this item in Dependencies?" causes LabVIEW to crash (all versions).

---

It never crashes for me. And I do use it.

---

Apparently it's not searching all of vi.lib because the file is in there (only once).

If I open ...\vi.lib\UDC\niceiplib.lvlib, I see this

I have no idea what "UDC" is or why any of my files would reference it.

I "fixed" the problem by removing the 64-bit version from niceiplib.lvlib; of course the problem will recur on a different machine or if LV is reinstalled or repaired.

For me, "Why is this item in Dependencies?" crashes all versions of LabVIEW on all machines.

[BertMcMahan]

That's a real bummer... I use Why is this in Dependencies all the time. It's extremely useful and have also never had it crash.

[paul_cardinale]

---

@BertMcMahan wrote:

That's a real bummer... I use Why is this in Dependencies all the time. It's extremely useful and have also never had it crash.

---

Turns out it doesn't always crash; just when I try to use it on missing items (which is usually the only time I want to use it).

[Bcousins]

I have just updated to Labview 21 sp1 f2 (32bit) and have received this same error as well. 
When checking "why is this a dependency" it referenced SFTP vi's

Fyi Updated same version up from f1 to f2

[JÞB]

---

@paul_cardinale wrote:

---

@BertMcMahan wrote:

That's a real bummer... I use Why is this in Dependencies all the time. It's extremely useful and have also never had it crash.

---

Turns out it doesn't always crash; just when I try to use it on missing items (which is usually the only time I want to use it).

---

You may have pushed the wrong button.

[paul_cardinale]

---

@JÞB wrote:

---

@paul_cardinale wrote:

---

@BertMcMahan wrote:

That's a real bummer... I use Why is this in Dependencies all the time. It's extremely useful and have also never had it crash.

---

Turns out it doesn't always crash; just when I try to use it on missing items (which is usually the only time I want to use it).

---

You may have pushed the wrong button.

---

I'm pretty sure I pushed this button: 

[d.w.b]

I have a LV 2015 SP1 32-bit project that has a niceiplib.lvlib dependency due to AppBuilder/AB_API calls which finds the 64-bit DLL as missing; why is this... does not crash on it. It does not prevent an .exe build but the AB_API calls are just in a VI that is in the project file not in the top level or always included VIs' hierarchy. The former behavior is the same when opened in LV 2023 Q3 32-bit (23.3.1f1).