GDS Installer for LabVIEW 2014

[vishots.com]

Ya, it was designed to reduce support calls.

But since VIPM looks at the windows registry for labview paths. Edit that.

[MikaelH]

The Extra Pre/Post Install VIs was needed to:

Remove the Read Only flag on all existing VIs so VIPM can overwrite them.

When uninstalling, I need to keep the vi.lib\addon\* VIs since they are needed for existing classes.

If you uninstall the tool, I don't want all classes you've made to be broken.

Ideally, there should be one package for the tool, and one for the supporting VIs under add-ons.

[AristosQueue (NI)]

I am not liking this entire process from beginning to end. Nothing in software I have worked on has been more frustrating than getting this working (although many things have been equally frustrating... I have an upper bound on how much software alone can make me before my fuses blow and I go do something else). It still isn't working. I'm going to spend today working on it more.

[MikaelH]

If you can send me the vip file, I can test it and try to debug it.

When I install the package I use the simple external VI, to do it.

The extra feature that installer has is to automatically remove the compiled code for some of the VIs.

[AristosQueue (NI)]

Cross your fingers, folks. It works on my machine... I'm testing other machines today to be sure.

A thousand thank yous to Michael for e-mails back and forth last night until we finally found what I was doing that was so special. A word to the wise... if you use PostInstall.vi or PreUninstall.vi, you cannot use subVIs in those VIs unless those subVIs are either part of core LabVIEW or are installed as part of the rest of your package into vi.lib or user.lib or instr.lib or resource (i.e. one of the symbolic directories). The VIPM installer doesn't know how to unpack the subVIs. So they end up as broken VIs and, apparently, LabVIEW isn't happy if a broken VI is installed as a callback -- I'm really unclear what happens to cause LV to crash, but it has to do with that VI being broken. Once it isn't broken (by moving my subVIs around) everything works.

Yeah!

Phew.

[FabiolaDelaCueva]

AristosQueue wrote:

Cross your fingers, folks. It works on my machine... I'm testing other machines today to be sure.

A thousand thank yous to Michael for e-mails back and forth last night until we finally found what I was doing that was so special. A word to the wise... if you use PostInstall.vi or PreUninstall.vi, you cannot use subVIs in those VIs unless those subVIs are either part of core LabVIEW or are installed as part of the rest of your package into vi.lib or user.lib or instr.lib or resource (i.e. one of the symbolic directories). The VIPM installer doesn't know how to unpack the subVIs. So they end up as broken VIs and, apparently, LabVIEW isn't happy if a broken VI is installed as a callback -- I'm really unclear what happens to cause LV to crash, but it has to do with that VI being broken. Once it isn't broken (by moving my subVIs around) everything works.

Yeah!

Phew.

Adding to the thank yous to Michael for taking time to help you with this!

Let me know when it is up and I can try it out on my machine as well.

Thanks,

Fab

[AristosQueue (NI)]

The VIP files are now available on my Google Drive. These MAY be final.

https://drive.google.com/folderview?id=0B56jSmCJjh0Ofm1qSHAxdlNsb0VxLXRrcUhPYVoxdFRZQTNQVk40Z1pNQTZu...

There are three files. These two are the kinds of installers that Mikael prefers to build: separate installers pre-mass-compiled for the targets.

NI-GDS_1.1.67()_LV2014-64.vip  -- installer for 64-bit LabVIEW 2014

NI-GDS_1.1.67()_LV2014-32.vip  -- installer for 32-bit LabVIEW 2014

The third one is likely to be the one that NI posts as the Powers That Be prefer a single download for all targets with mass compiling after install, especially as this handles situations where LV has an F1 patch where VIs benefit from mass compiling.

NI_GDS_2014-1.1.68.68.vip

BUT THERE IS A PROBLEM WITH THE THIRD FILE. MICHAEL/MIKAEL:

I can see VIP install. Yes, I see it run mass compile. But launching LV 2014 32 bit is still slow. Why? Because -- get this -- NOT ALL THE VIs ARE MASS COMPILED. This causes the launch of 32-bit to be dog slow unless you run a manual mass compile later (because none of the VIs are marked as "source only" so background compiles do not get saved). One of the files that is not mass compiled is "ClassWriterGOOP300.lvclass:GetClassTemplates.vi". Now, why the templates are even needed by the project providers AT LAUNCH TIME is beyond me, but that's a deep architectural issue that I'm not going to address today. What I'm far more curious about is why VIPM is only mass compiling some of the files.

Guess what... the reason is the files are... READ ONLY. Mass compile won't help anything. *head bang*

Why are VIs being installed read-only? Is this typical of VIPM or am I looking for some setting in Mikael's VIPM wrapper? How do I fix this? Is there an option in VIPM to turn on source-only for all the files? Is there a way to turn off read-only installation?

[AristosQueue (NI)]

Note that if you wait through the long first launch, you'll get a dialog that says that the GDS needs to recompile ... if you use THAT DIALOG and not the regular mass compile, it knows enough to remove the read-only flag from the VIs.

[vishots.com]

VIPM looks at the files that were just installed from any package and does a check to see if mass compile is necessary. It uses the modifications bitset property on every VI to see if a save is necessasry. If there is modification to the VI then it saves it. This could be a good thing or a bad thing. Depends on your use case. There's no "force save" feature in VIPM.

So since the package is built on LV2014. If you install it on LV2015, it will save all the VIs because the mods bit is set.

[AristosQueue (NI)]

This is a different case. The VIP was built using 2014 64-bit. It is now installing into 2014 32-bit. VIPM is seeing that it needs to do a mass compile and is running the mass compile, but because all of the VIs are read-only, the mass compile has no effect. The VIs get loaded, compiled and Save gets called, but the files on disk don't update because of the read-only flag, so they are still not compiled when LV launches again. I need the VIP installer to not mark the VIs as read-only or mark the VIs as "source only"... one or the other.