Frustrated by VIPM 2014

[Mellroth]

I’m trying to build a package using some of the newest features in VIPM, licensing and palette binding, and is really frustrated over VIPM. I will try to list some of the most frustrating things here, feel free to separate in different threads, as I don’t have more time to spend on searching for workarounds or understanding bugs in VIPM.

 

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 run

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

 

/J

Original system (working without inclusion)

* Windows 7 home premium

* LabVIEW 2012

* VIPM 2014 (build 1941)

 

New system

* Windows 7 Pro

* LabVIEW 2012 SP1

* VIPM 2014 (build 1941)

[Mellroth]

The list grows...

 

An earlier vipb-file containing name-spacing of a number of lvclasses are now built without namespace added to the files.

Looking in the vipb file saved by VIPM 2014 it seems to be a bug with the URI separator, e.g. the following text is from one vipb-files after I showing that if I manually add namespacing again, the item now has two entries with different separators

 

<Namespace_Overrides>

<Path>WF-Fingerprint\WF-Fingerprint.lvclass</Path>

<Namespace_Type>Suffix</Namespace_Type>

<Namespace>_wireflow</Namespace>

</Namespace_Overrides>

 

<Namespace_Overrides>

<Path>WF-Fingerprint/WF-Fingerprint.lvclass</Path>

<Namespace_Type>Suffix</Namespace_Type>

<Namespace>_wireflow</Namespace>

</Namespace_Overrides>

 

Basically this means that all old vipb configurations is useless until we manually go in and fix the namespacing, or until it is fixed.

 

/J

[Mellroth]

The same problem appears with additional destinations

 

<Destination_Overrides>

<Path>examples\WireFlow_Finger Print Reader.bin3</Path>

<Destination>0</Destination>

<Additional_Destination>true</Additional_Destination>

<Additional_Destination_Index>0</Additional_Destination_Index>

</Destination_Overrides>

<Destination_Overrides>

<Path>examples/WireFlow_Finger Print Reader.bin3</Path>

<Destination>0</Destination>

<Additional_Destination>true</Additional_Destination>

<Additional_Destination_Index>0</Additional_Destination_Index>

</Destination_Overrides>

 

In this case it means every package with examples and corresponding exbin files has to be manually updated to support searching in example finder

[Jim Kring]

Hi Jonas,

 

I'm sorry for all the troubles.

 

Regarding the password-protected source libraries, thanks for the description and ideas for ways we could implement support. You're right that the build occurs in a difference context than the pre-build. I'll think a little more on this issue and ways we might be able to work around it.

 

Regarding the path separator issues, which version of VIPM was used to create your older .vipb files? I'll see if we can reproduce it.

 

-Jim

[BrianGShea@NTS]

 

1. Library/class palette errors

 

 

Item #1 does not work on a very basic class with out locking or passwords. I was able to get the palette to attach to a library. Unfortunately 90% of my code base is OOP and adding the palette to the library does not allow it to show up on VIs that are part of a class within the library.

 

It seems like VIPM is able to add the mnu file to the class, but is unable to set it as the default palette. You can modify the class after it is installed through the right-click properties and then set the palette, however, this is tedious and i cannot reasonably expect users of my packages to manually do this. I sure hope this gets fixed in the next release. I'm using the latest build as of April.

[BrianGShea@NTS]

Item #1 does not work on a very basic class with out locking or passwords. I was able to get the palette to attach to a library. Unfortunately 90% of my code base is OOP and adding the palette to the library does not allow it to show up on VIs that are part of a class within the library.

 

It seems like VIPM is able to add the mnu file to the class, but is unable to set it as the default palette. You can modify the class after it is installed through the right-click properties and then set the palette, however, this is tedious and i cannot reasonably expect users of my packages to manually do this. I sure hope this gets fixed in the next release. I'm using the latest build as of April.

 

I found 2 basic errors when VIPM tries to set the default menu for a class.

1) the DefaultMenu xml tag does not match the project item's Name tag. These are case sensitive.

 

Example:

<Property Name="NI.Lib.DefaultMenu" Type="Str">functions_nts_lib_Object_Attributes.mnu</Property>

<Item Name="functions_NTS_lib_Object_Attributes.mnu" Type="Document" URL="/<menus>/Categories/ReBT/functions_NTS_lib_Object_Attributes.mnu"/>

 

 

Notice the missing capitalization on NTS

 

2) The URL of the Item is does not start with '/<menus>/' it starts with a series of ../../../ as a relative path from the installation location of the class.

 

Here are two VIs that can be used to fix the problem and allow the default palette to work. Please note that is not a solution for the community, however it is a demonstration of the fix. It could be a solution if Post Install scripts included dependent VIs or this VI was pre-installed as a package that other packages were dependent on so that this VI exists prior to installing other packages.

 

I hope that these are fixed in the next release of VIPM.

 

Thanks,

VIMP Post-Install Custom Action - Decompress Libraries.vi

VIPM Fix Class Palette.vi

[WhiteFang]

Hi Brian, thank you for coming up with a fix for this, I hope this fix (or a fix) gets built into the next VIPM update. -Perhaps a JKI rep' could comment on this in the thread?