Application with large 3rd Party Library

[bhawkins]

Hello Team Caphyon,

Learning more about your product each time we use it and try something different or test it out with different situation. Really a great product.

Wondering if you could offer suggestions with our situation. We are trying to minimize downloading for Updating existing applications. I have a pretty good understand of the differences with upgrades and patches. Patches are great. When we do updates that involve uninstall and reinstall I think our msi are overly fat because we were including dot net 4.0. Obviously if the client has our software installed ... there is no need to have dot net 4.0 when considering updating and patching. Patching totally removed the dot net .. however upgrades would include it.

Originally we were not creating an EXE setup file (Media - Bootstrapper tab) and our setup.msi were 94 megs. You must have changed something with the Bootstrapper as now in version 9.01 if we use this option ... and select leave install files outside; the prerequisite for dot net are also not included in the msi either (we use the dotNetFx40_Full_x86_x64.exe).

This was extremely good news as it has reduced the size of our Setup.msi to 43 megs (without the 49 megs for the dotNetFx40_Full_x86_x64.exe). (note file sizes are approximate).

My question is this ...

Our application also uses a third party library. This Library is approximately 75% of the application size (without dot net 4.0). This Library will not change that frequently. It is not an issue with patches as it is effectively removed for patches. However, for updates it would be part of the msi.

These libraries may change over time .. however likely our application would change more frequently.

Is there a scheme by which we can separate out this third party library and then only update it when required?

The library is to be installed in the same folder as the application, in a separate subfolder however:

Application
System
3rd party library

These are just dlls that are localized for our application use only. Not putting them in Windows System32 folder or registering them for system use.

I am thinking:

4.0.0 Install with Library and dot net 4.0

patch to 4.0.1
patch to 4.0.2
patch to 4.0.3

upgrade to 4.1.0 (library has not changed)

patch to 4.1.1
patch to 4.1.2
...
patch to 4.1.8

upgrade to 4.2.0 (with new library)

and so on

Any help you could offer would be greatly appreciated.

Cheers,
Bruce

[Bogdan]

Hi Bruce,

The easiest and cleanest solution for your scenario is to separate your libraries into a separate package. Then you can add the package as an URL prerequisite to your main package, so it gets downloaded only when you release a new version.

To easily track if a new version is required you should increase its version every time a change is being made in it and also store it in a registry key, so you can use it as an install condition for the prerequisite. This way the main installer will download and install the prerequisite only if the version found on the machine is older then the one from the package.

Would this solution fit your requirements?

Regards,
Bogdan

[bhawkins]

Bogdan,

Thanks! I am interested in you solution Just need some more details.

As a separate msi ... I can see this for basically unrelated prerequisites (dot net 4.0 is completely separate .. but required).

Since it would be a prerequisite that is Feature Based, we will know the application folder that will be used, so we could use this if that location is available to us to use. We want the application totally self contained in it's own folder.

Another issue is the Library installation is then not associated with our application installation. Just like .. if we install dot net 4.0 as a prerequisite - it is not uninstalled when we uninstall our application (client uninstalls permanently) or we uninstall and reinstall for major updates.

So I guess I am missing something in this solution. I hate being a newbie. Can you explain what you are thinking.

Cheers,
Bruce

Note ... 39 megs is not a huge file with fast internet, however, we have customers in Africa where bandwidth is paid for by the minute access, so for them this is important. That why we are willing to do this extra work involved to solve this.

[mihai.petcu]

Hi Bruce,

Since it would be a prerequisite that is Feature Based, we will know the application folder that will be used, so we could use this if that location is available to us to use. We want the application totally self contained in it's own folder.

You can try to pass the APPDIR property from the main package as a formatted reference argument through the prerequisite's "Install Command Lines" -> "Full UI" field.

Another issue is the Library installation is then not associated with our application installation. Just like .. if we install dot net 4.0 as a prerequisite - it is not uninstalled when we uninstall our application (client uninstalls permanently) or we uninstall and reinstall for major updates.

This is not necessarily an issue. You can easily uninstall feature-based or post-install prerequisites using the appropriate command line. The command lines can be set from the "Prerequisite Setup Files Tab". An alternate solution to this is described in the "How do I uninstall another MSI package when my application is uninstalled?" user guide article.

My colleague Bogdan is currently on vacation but he'll be back at the office next week.

All the best,
Mihai