1. Library/class palette errors
a.If the source library is pwd protected the palette linking doesnít work as expected. I guess this is because VIPM cannot correctly set the default mnu in the lvlib.
b. If the palette is linked to an lvclass it requires all class members to be not-protected, because all member VIs holds a record of the parent class password . The build succeeds but the palette is not correctly linked to the class
c. Both the problems above would be resolved if the building process could ask for passwords on source files.2. VIPM clears password cache after Pre-build
a. To solve the password errors with palettes I tried to use the pre-build VI to add the source code passwords to the password cache. Testing this externally works just fine, but VIPM seems to clear the password cache or is not running the actual build in the same context as the Pre-build VI.3. Post-build action is not always executed.
a. Trying to work-around (again) the palette linking issue by adding a postbuild step that correctly sets the default palette using correct source passwords etc. fails because the post-build VI is not always executed!
b. I verified this by trying to display a dialog before my post-build actions could run4. Packages are included in the package even if they are specified as external
a. I scan the project for dependencies, and remove the items I like to be internal from the dependency list, but for some reason all linked dependencies are added as internal.
b. This is true for new vipb packages as well as converted from older versions.
c. After many hours of debugging, I noticed that the same source folder (fresh from svn) generated a VIP-file without internally added dependencies. This feels really bad; the same versions for VIPM and slightly different LabVIEW versions generates different outputs on different computers. (all dependencies have the same version on both systems)5. Internal dependencies get an additional 32 bytes (!) per level of dependency, i.e. if a linked library has internal dependencies the resulting names are 64 bytes longer. Meaning that it is easy to reach the limit of 256 bytes and get build errors because of too long file paths.
6. To resolve too long build paths I tried to change the temp build folder in the Options dialog to c:\temp. This didnít affect the build output, even if the option dialog listed the correct temp folder. I had to close the package builder and change the folder in the option dialog in the main window
7. Even after building successfully with the new temp folder, installation might fail because of the combination of forced inclusion and the 32 bytes added to each level.
8. Changing temp folder to a non-existing folder reverts the temp build path to default instead of previous settings without notice.
9. Passwords are stored in clear text in the vipb file, and I would really prefer if there was an option to give the passwords for the source files by dialog (to solve linking issues with locked source files), and the same type of option for build outputs, i.e. let the user set a master password by dialog, and add ďUse master pwdĒ or something similar to the options.
For now I have to keep my old laptop hanging around until this forced inclusion is sorted out. Another option is to locate a VIPM 2013 download and downgrade the vipb file and see if that resolves this issue. The last resort is to go back to OpenG package manager for packaging of our tools.
Original system (working without inclusion)
* Windows 7 home premium
* LabVIEW 2012
* VIPM 2014 (build 1941)
* Windows 7 Pro
* LabVIEW 2012 SP1
* VIPM 2014 (build 1941)