Vis broken when moved from LV2015 32 to 64 bit and vice-versa

[instrumento]

I have this large set of files under revision control.

Check them out on a Windows 7 Enterprise 64 bits, open them with LV2015 SP1 f10, 64 bits, everything is fine.

Check them out on a Windows 7 Enterprise 32 bits, open them with LV2015 SP1 f10, 32 bits, one VI is missing!  Selecting replace and navigating to the subdirectory where the file is, everything is fine again.

Copy the missing file, the calling file and its caller (the top level) over to the 64 bit system, another file has a bad linkage.

Rinse repeat.  How can I even find what's wrong?

[billko]

---

@instrumento wrote:

I have this large set of files under revision control.

Check them out on a Windows 7 Enterprise 64 bits, open them with LV2015 SP1 f10, 64 bits, everything is fine.

Check them out on a Windows 7 Enterprise 32 bits, open them with LV2015 SP1 f10, 32 bits, one VI is missing!  Selecting replace and navigating to the subdirectory where the file is, everything is fine again.

Copy the missing file, the calling file and its caller (the top level) over to the 64 bit system, another file has a bad linkage.

Rinse repeat.  How can I even find what's wrong?

---

How can we even know?

[billko]

Lesson learned.  The responses will only be as specific as your question(s).  For example: What VI was missing?  Was it one that came with LabVIEW?  Is it a toolkit VI?  Is it one of your own?

[instrumento]

Hmm, its kind of a generic question.  In this case they are all our VIs. 

They have been working under LV2015 64 bits, previously LV2012 64 bits, all on Win7-64 for a long time.  I now need to build the same with LV2015 32 bits, Win7-32 and when running project build I get a broken VI.  LV complains the VI is missing.  I right click, replace, navigate to where the VI is and voila, fixed.

If I save the two VIs and copy them back to the 64 bits system, open it there, some other VI linkage is bad.  I go through the same fix procedure, and voila, fixed.

There's not a clue of what's broken.  It is either missing VI or bad linkage.   What am I supposed to do?  Go back and forth between the two systems until everything is fine?  It's the same set of files, under the same hierarchy. LV2017 32 and 64 disagree over some internal stuff that I don't have access to.

[billko]

---

@instrumento wrote:

Hmm, its kind of a generic question.  In this case they are all our VIs. 

They have been working under LV2015 64 bits, previously LV2012 64 bits, all on Win7-64 for a long time.  I now need to build the same with LV2015 32 bits, Win7-32 and when running project build I get a broken VI.  LV complains the VI is missing.  I right click, replace, navigate to where the VI is and voila, fixed.

If I save the two VIs and copy them back to the 64 bits system, open it there, some other VI linkage is bad.  I go through the same fix procedure, and voila, fixed.

There's not a clue of what's broken.  It is either missing VI or bad linkage.   What am I supposed to do?  Go back and forth between the two systems until everything is fine?  It's the same set of files, under the same hierarchy. LV2017 32 and 64 disagree over some internal stuff that I don't have access to.

---

The report on bad linkages is quite specific about what was cross-linked.  There's a save button on the dialog.  Next time this happens, save the report.  The fix will depend upon what is inside that report.

[instrumento]

---

The report on bad linkages is quite specific about what was cross-linked.  There's a save button on the dialog.  Next time this happens, save the report.  The fix will depend upon what is inside that report.

---

No such button here. 

Went back and forth between the 32 and 64 bit versions three times, with a different VI missing each time, which i fixed by replacing it with the same VI in the same exact hierarchy place.

The bad linkage was probably because one of the VIs was a polymorphic and LV got confused about the connector pane.  (Context Help did say: " was not found Expected path: NULL)

Now it is fine on both versins, but things like this worry me a bit, as I have a bunch of dynamically load stuff that may eventually break at run time.  Hopefully not.