Reducing Size of LV8 Installers

[mdennie]

At first glance, building a fairly simple example executable in LV8 results in an EXE of just over 1 MB.

Creating an installer results in a folder 'Volume' consuming almost 70 MB. Sheesh!

Part of this is the LV Runtime installer (about 20 MB), and part of it is the Math Kernel Library (about 6 MB) I just read about in a related thread.

But what is all the other stuff {'MU' (2 MB), 'MDF' (8 MB), 'svcloc' (1.4 MB), 'logos' (13 MB), 'license' (the Engilsh license is 65K but the Korean license is over 1 MB), and 'support files'} and are there ways to reduce it?

Any help or suggestions are appreciated, or links to similar topics elsewhere (I haven't found any).

Thanks,

-- Matt

[jbernable]

Hi: Have you resolved this problem?, I have the same problem! If you know how, please help me

Regards

Julio

[G-Man]

Hi Matt,

Some time ago (when using LV6.1) I was faced with a similar situation. Now with LV8.0/1/2 I am faced with the same problem once again.

Back in 6.1, I was able to build installers without including the runtime engine at all. As long as the necessary support libraries (dlls) are included in the installation and located in the same folder as the resultant executable or in the windows path things seemed to work alright.

For example, a simple application that uses serial communication, serpdrv.dll would have to be included in the path. To support basic functionality there were a couple of object libraries (don't remember the names sorry) that also had to be included. If you're building a more complex application that uses vision, motion, or other types of added labview functionality, then I'm not sure if you'll be able to get away with 'cheating' like this.

Today I am focussing my efforts on finding a 'reverse engineered' approach to building custom distribution packages as I too do not want to build a 130+MB installer to support a 3MB application In my case, I have to include support for VISA (runtime enging is 130MB I think). I beleive this can be avoided by simply including the visa32.dll as a support file. I'll keep you posted as I find anything out.

I suppose I should also check in with the good folks at NI to find out if these methods breech the EULA (license).

Regards,

Doug.

[Rolf Kalbermatter]

Hi Matt,

Some time ago (when using LV6.1) I was faced with a similar situation. Now with LV8.0/1/2 I am faced with the same problem once again.

Back in 6.1, I was able to build installers without including the runtime engine at all. As long as the necessary support libraries (dlls) are included in the installation and located in the same folder as the resultant executable or in the windows path things seemed to work alright.

For example, a simple application that uses serial communication, serpdrv.dll would have to be included in the path. To support basic functionality there were a couple of object libraries (don't remember the names sorry) that also had to be included. If you're building a more complex application that uses vision, motion, or other types of added labview functionality, then I'm not sure if you'll be able to get away with 'cheating' like this.

Today I am focussing my efforts on finding a 'reverse engineered' approach to building custom distribution packages as I too do not want to build a 130+MB installer to support a 3MB application In my case, I have to include support for VISA (runtime enging is 130MB I think). I beleive this can be avoided by simply including the visa32.dll as a support file. I'll keep you posted as I find anything out.

I suppose I should also check in with the good folks at NI to find out if these methods breech the EULA (license).

Regards,

Doug.

With LabVIEW 8 and 7.x too things are not as easy anymore. There is a lot that gets installed and a lot if it might be sometimes redundant but other times it can be absolutely crucial to your application. I guess NI had the choice to make this fully configurable with a 20 page dependancy chart that tells you which VI functionality requries which external module and which external module again depends on other external modules or create a more catch all installer system.

The first choice would have caused a lot of documentation work, additional testing and such and prompted 90% of the LabVIEW users to complain that creating a LabVIEW executable installer is a pain in the a**. The other solution is simpler to deal with, needs less documentation, is MUCH easier to support for technical support, and costs a bit of media space. But with 500GB harddisks and 4.5GB DVD media currently that is a concern a lot of users don't even think about.

As to VISA: No VISA32.dll is only a wrapper interface. The actual interfaces for the different VISA IO resources are in different other DLLs that need to be registered correctly for VISA32.dll to be found and there is at least one more VISA runtime support DLL that needs to be installed too. Also this does not include the lower level drivers such as NI-488, NI-Serial, NI-PXI etc etc which need to be installed too if you happen to use them and are usually part of a default NI-VISA installation too.

And in order for you to configure the actual VISA resources at all you will want to have Measurement & Automation Explorer installed too, which is a rather big beast with quite some more dependancies.

Rolf Kalbermatter