LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

BuildSpec - Wrong Bitness

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.)

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 1 of 12
(1,655 Views)

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.

0 Kudos
Message 2 of 12
(1,642 Views)

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)

---------------------------------------------
Certified LabVIEW Developer (CLD)
0 Kudos
Message 3 of 12
(1,612 Views)

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

paul_cardinale_0-1652890178073.png

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.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 4 of 12
(1,606 Views)

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.

0 Kudos
Message 5 of 12
(1,598 Views)

@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).

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 6 of 12
(1,572 Views)

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

0 Kudos
Message 7 of 12
(1,471 Views)

@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.


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 12
(1,434 Views)

@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: paul_cardinale_0-1658240874342.png

 

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 9 of 12
(1,429 Views)

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).

0 Kudos
Message 10 of 12
(258 Views)