Renaming breaks packed library in LV 2015

[littlesphaeroid]

I have a post-build action in LV2014 that renames a packed library after the build, appending the build's version number to the packed library's filename, and incrementing the version number of the build. This has proven to be an easy way to maintain packed library versions and ensure the correct code is being distributed in our test system.

In LV2015, this breaks the library. I have confirmed that programmatically or renaming the packed library breaks the library. An error dialog is generated that indicates the VIs are being searched with an absolute path involving the library's original name. 

This same method still worksfor executables, however.

In the image you see that GetHelpDir.vi is not found, which is not called in this library directly, AFAIK, but any VI called may appear in this dialog. Save Data.lvlibp was the original name of the library, but it was renamed Save Data 1.0.lvlibp, and thus this VI is not found.

Why would this be?

[kosist90]

Do I understand correct, that now you've upgraded your lvlib to LabVIEW 2015, and rebuild it to project packed libraries? If so, could it be that first VI what you build and rename, refer to ppl still built in LabVIEW 2014, and that's why it can't load from it?

Could you then remove all packed libraries, mass compile your code in LabVIEW 2015, and try to build packed libraries again?

Sincerely, kosist90

Caraya test framework for LabVIEW – convert your VIs to test code!

[littlesphaeroid]

No, the project file does not reference any packed libraries. The PPLs are build from lvlib's.

[littlesphaeroid]

Are you suggesting that renaming the packed library does not break it on your system? that would be great!!

BTW, I am being forced ot upgrade part of our operation, due to a piece of NI hardware/sw we are using that requires LV 2015. I would prefer not to have to upgrade, due to this sort of issue, as we are maintaining literally hundreds of testers in our company's manufacturing facilities, and are ideally using a single version of LabVIEW and rarely upgrading.

[kosist90]

---

@littlesphaeroid wrote:

No, the project file does not reference any packed libraries. The PPLs are build from lvlib's.

---

That is clear; I thought that built VIs (after build) refer to VIs from alredy build project packed libraries. And if they relay of ppl from other LabVIEW version than theirs, it will cause the problem... But, I'm not sure whether you have this case now.

Sincerely, kosist90

Caraya test framework for LabVIEW – convert your VIs to test code!

[littlesphaeroid]

This problem persists in LV2017. I am unable to rename a packed project library, as it makes the library unusable. 

I wonder if anyone could verify that it is possible to create a packed project library and rename it (in windows or programatically) and have it still be openable?

[Yamaeda]

The error message is pretty clear, the lvlibp links to other vi's including the lvlibp's name. What you'll need to do is build and use a Pre-build VI that changes the name of the target in the project before building.

Check Get Build Specification Version and Set Build Specification Version

/Y

[littlesphaeroid]

I thought of that approach, and I will try it. Thank you for the tip!

Still,this is strange. In LV2014, the project file name could be changed after it was built. beginning with  LV2015 changing a PPL filename kills the library. Imagine if this were the case with an executable. Wouldn't that be problematic? 

it seems now the VIs within the project are not found relative to the packed project itself.

[crossrulz]

I would argue there was a bug with 2014 and fixed with 2015.  The VIs in the PPL have a logical name set to the name of the PPL.  If you rename the PPL, then all of the VIs have an invalid name and they cannot recompile to use the new name.

[littlesphaeroid]

This is an interesting perspective. But, as a corollary, what if you were unable to rename an executable after it was built? Would this be considered acceptable behavior? Since a PPL is much like an executable, and the VIs within it are (obviously?) relative to the container, including the current actual name of the container makes more sense to me than the current behavior. I can't see how what existed in 2014 was a bug. It never failed to work for me.

I'll code up my pre-build action to get the same effect now! Thanks!!!!