Advice on how to manage software suites

[DrBob]

Hi
We are planning to switch to AI for our products and I would appreciate advice on the best way to organise our titles.

We currently ship 7 different titles. The flagship title is distributed in 17 languages and all titles share a lot of common features, some of which are user options. Our current inventory is about 30 CDs. A typical install is about 1Gb. We issue updates about once/month. We also include an on-line updater that downlaods patches from our web site.

When we switch to AI, how would you recomend we arrange our products? Should we try to build a single massive project so that we can be sure the GUIDs on all common features/components are correct, or is it better to split the project, either by software title or have each a project for each title/language? If we split the project should we be using merge modules or is there a better way to keep the shared features in sync? From the user perspective it would be nice to have a single entry in control pannel for all titles, but it should not show end users any features that are not installed. All installs will be administrative installs and apply to all users on the machine. We would like to end up supporting three different media:
a) Single file installers for distribution by CD.
b) Web install with minimal downloads
c) Web update (possibly part of web install)

Thanks in advance for your help.

[GabrielBarbu]

Hello,

Thank you for taking your time to evaluate Advanced Installer.

When taking web installs into consideration, it is also a good idea to consider your user base that does not have access to internet. Deploying a single massive installer including all your products would be considered inefficient especially should the user only need one of the titles. Thus a separate installer for each of your 7 products might be a good solution.

However having different installers would mean multiple entries in Control Panel.

Also, we support creating multilanguage installers which means you can have one installer for all 17 languages of your product. Common features would be best placed in merge modules. This would indeed ensure having the same GUIDs.

Supporting a web install would mean the opposite. All your products would have to be incorporated into one installer and organized as features. This would the web install implementation. It would also mean one single entry in Control Panel.

Since you want to support both methods, I can only see this happening if you create the web based installer and the single file installers separately.

We do provide our own automatic updates system as can be seen in our guide on the Auto Updater.
You can also integrate your own updater through the use of custom actions.

Do let me know if you have further questions and I will be glad to assist.

Best regards,
Gabriel

[DrBob]

Thanks for the quick reply.

Is the following realistic:

1) Each feature is managed as a single aip file and built into a merge module. We maintain a library of merge modules for each feature.

2) We call our software suite a 'product' so that it presents to the end user as a single entry in Control pannel. The aip file for the product defines a build for each title/language combination (I assume unreferenced resources are not included in the MSI file so the size should be managable). I think this means we need to use the 'Allow side by side installs option. When we build all we get a set of MSI files that we can ship on CDs or make available as web downloads.

3) For on-line installs and updates we copy the aip file from (2) above (so we have the same GUIDs), but change the build settings to make the project suitable for web updates.

I have not yet evaluated your auto updater and web installer, but the features looked very encouaging.

Rob Series

[GabrielBarbu]

Hello,

1) Each feature is managed as a single aip file and built into a merge module. We maintain a library of merge modules for each feature.

This is a Merge Module project which can be created by Enterprise license holders. Our guide on merge modules gives more details on how to use this feature.

2) We call our software suite a 'product' so that it presents to the end user as a single entry in Control pannel. The aip file for the product defines a build for each title/language combination (I assume unreferenced resources are not included in the MSI file so the size should be managable). I think this means we need to use the 'Allow side by side installs option. When we build all we get a set of MSI files that we can ship on CDs or make available as web downloads.

You are specifying that you need a single entry in the Control Panel. However you are mentioning you are expecting multiple MSIs. Are you planning to use a single aip file to include all your titles (with all their resources), then create multiple builds each installing only one title? This is not a viable solution, as your builds(titles) would not be able to reside together on the same machine (because they would have the same Product Code and Upgrade Code). If your product is organized into titles, you would either have to create an aip file for each of them or you would have to place them all in the same aip.

I would suggest you go with the second option. You would organize your titles into features in a single .aip project file. Then the behavior would be the following:
- for deploying on a CD/DVD, you would include the msi and the cab files (which are placed outside the msi) on the media, and the user would be able to select which feature (title) would be installed.
- for a web install you would deploy the .exe bootstrapper. The msi would reside on your web server to be retrieved (downloaded) by the .exe bootstrapper. Then the user would continue to select which title to install and depending on his selection the proper titles will be downloaded and installed.
- everything would be found in Control Panel under a single entry. The user would click it and select "Modify" to either install or uninstall additional titles.
- there would be no need to edit the .aip file.

Let me know if you are satisfied with my suggestion.

Best regards,
Gabriel

[DrBob]

Thanks for the reply. I think the second option is promising but we will need to do quite a number of experiments before we get it right. I hope a single aip file will be manageable and scale well. We have gone ahead and purchased the enterprise version because it looks like we will need merge modules. I am very impressed by the level of support you give for your product.