How to use a custom vi.lib in 8.2 or General Installer Questions!

[romulus]

Hello,

I'm currently in charge of upgrading a large application 7.1 -> LV 8.2. I've run into a problem which seems to have occured in LV 8.xx. The way our application is set up is that it uses its own stripped down version of vi.lib in order to avoid having to use LabVIEW's Run-time environment which comes in a "whopping" 95MB (not my opinion 😉 ). So a kind of a workaround has been used where we've used a custom, stripped vi.lib and a set of custom tools written to install the needed files when the application is being installed on a computer without LabVIEW on it. (we use InstallShield & custom tools for building the project, we use the app builder only to create the application's .exe but no other features in it).

The issue now seems to be how 8.2 handles vi.lib references as well as a new, strange packaging method (e.g NI_AAB.lvlib, i might be mispelling this) which has the base/pro options and seems to check for what version of LabVIEW you're using. Now I did manage to get our application converted to 8.2 and run succesfully. The problem I ran into is that after a couple of days, LV seems to get confused about its vi.lib references and sometimes uses the vis from the application's vi.lib and sometimes from its own vi.lib. That has succesfully broken the Mass Compiler tool. I also constantly get messages that a VI expected to be in LV's vi.lib was loaded from my vi.lib and no matter how many times i recompile/save it, it doesn't go away (unlike 7.1).

Another worry I have is that if we continue using a custom vi.lib we'll run into problems with patching LV, like when the highly anticipated 8.2.1 patch comes out. Basically I would like to know what a good method of doing this would be in LV 8.2 (if there is such a method) or if going with the Run-Time Engine installation and making the application use everything in LV's vi.lib is the best way to go. I really need a definitive answer about this. Help is greatly appreciated.

[TCPlomp]

Why would you use your own version of vi.lib for applications? The exe you build has all the needed VI's inside it. My exe's range from 0.5 to 5 MB, the runtime engine is 95 MB, but you'll need that anyway?

However I don't think I have a solution for this, sorry

Ton

[romulus]

Ok i might have not gotten my point across.

The reason we're using our own vi.lib is to not have to install the 95MB runtime engine (so the user can quickly download our app). The vi.lib doesn't contain any of our code, it contains vanilla LV code just that it has only the functions we're using so that when we use a professional quality installer like InstallShield, we drop the vi.lib file and we're done with it, no need for Runtime engine. Our exe stays small that way and everything is nicely split up and we don't have to use LabView's installer.

Message Edited by romulus on 01-31-2007 08:10 AM

[SamboNI]

As you may imagine, this is not the recommended way to distribute applications. We recommend simply building the exe and either bundling the run-time engine or having the user download that separately.

Issues may crop up if you try some other method, and unfortunately I can't be of too much assistance there.

Best regards,

[Joe_H]

This is done quite a bit actually. But my question is why not just package everything in one place with the LV Installer, run time and all. if you need to upgrade you SW then the run time engine will only be installed once. Or you could just make the run time engine a requirement and have them download it free from NI. This way you installer and EXE are small. I would hate to see how you would handle Daqmx calls with this type of framework and installation.

[romulus]

---

@Jhoskins wrote:
This is done quite a bit actually. But my question is why not just package everything in one place with the LV Installer, run time and all. if you need to upgrade you SW then the run time engine will only be installed once. Or you could just make the run time engine a requirement and have them download it free from NI. This way you installer and EXE are small. I would hate to see how you would handle Daqmx calls with this type of framework and installation.

---

To answer your questions:

1) We want to use InstallShield to create the install package which will include the built .exe of our app and all the other files.

2) Our software is mostly used in factories and a lot of times in China on a production line where access to the net is out of question.

3) DAQmx calls work fine, we rip the needed daqmx vis from the libraries.

4) I absolutely agree that this is a horrid way of doing this and something I didn't implement or come up with. This was done by a programmer before me and all hacks are destined to fail.

I will do this the proper way and have InstallShield check if the RTE is installed or not.

A reply to the NI poster: Your RTE does have to be installed more then once because when you guys release new LV versions, there's always a new version of the RTE for that patch. As long as there's no new LV versions, you're right, our app will actually become smaller because the RTE doesn't have to be installed.

[tst]

---

@romulus wrote:

2) Our software is mostly used in factories and a lot of times in China on a production line where access to the net is out of question.

---

But you're saying they need to download your installer, so at least at some point they should have access to the net, where they can download the RTE.

My suggestion to you - see if you can say no. Tell whoever's in charge that this sort of thing will not get any support from NI and that it is quite likely to break at some point. Instead, just try to come up with an easy way of getting the clients to download the RTE installer and install it.

[romulus]

I completely agree with you. I managed to convince the person in charge to go with the correct way of doing this and now I'm on the long, painful road to recovery. The problem is that LV comes with horrible help for the Project Explorer and now I'm getting a lot of broken dependencies even though i mass-compiled everything and my project is not complaining, I'm now getting bad dependencies which I don't know how to fix from the project explorer, it just gives an option to open the file and remove it from the dependencies list or not do anything at all....arghh.