AquaComm
Posts: 13
Joined: Wed May 06, 2020 3:25 am

Designing a Multi-Project Solution installer.

Wed Jun 16, 2021 2:49 am

Hi,

I have a product that consists of 5 separate windows programs as well as a couple of windows services, a website and a couple of web API's. At present I use a competitor Installer but I am moving it to AI Unfortunately the process cannot be automated. The current installer is one monolith.

I am thinking of creating several AI installers for most parts of the product so that I can more easily manage updates using AI. For example, there is one program for the UI, another for Setup etc. There would be one "Master" installer that would then run each subsidiary installer and allow me to issue updates specific for each one.

Before I spend a lot of time on this I am hoping someone could advise me on the pros and cons of such a design pattern.

Thank you.

Catalin
Posts: 4224
Joined: Wed Jun 13, 2018 7:49 am

Re: Designing a Multi-Project Solution installer.

Wed Jun 16, 2021 2:52 pm

Hello,

I'd say that this is quite a common scenario.

We have the following article:"Creating Suite Installations" which should get you started.
Before I spend a lot of time on this I am hoping someone could advise me on the pros and cons of such a design pattern.
To be fully honest with you, I am not aware of any con for this method (almost every setup out there has prerequisites packages in addition to the main application - i.e. an application written using the .NET Framework will require .NET Framework on the machine in order to run). A pro, however, would be the fact that it is somehow easier to manage everything from the "master" installer.

Hope this helps!

Best regards,
Catalin
Catalin Gheorghe - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube

AquaComm
Posts: 13
Joined: Wed May 06, 2020 3:25 am

Re: Designing a Multi-Project Solution installer.

Fri Jun 18, 2021 1:37 am

Thank you for pointing this article out for me as well as your recommendations.

One stumbling block I have is that each of the projects that make up the suit have a large number of references to the same dll's. These would add approx 20 meg to each projects aip. Ideally each aip would check for the existence of a dll residing in a common folder and then add it to the GAC. If the dll file was not in the common folder then the aip would download it and process it accordingly.

I'm not certain that in this day and age that download size and disk space usage are of such a major concern but is there some AI mechanism available to me to easily manage these dll's?

I assume that a separate aip could be created for these dll's (and other common data) for which it's aip's "Check for Updates" could be initiated as a prerequisite for each dependent aip ensuring that the dll will be in that common folder.

AquaComm
Posts: 13
Joined: Wed May 06, 2020 3:25 am

Re: Designing a Multi-Project Solution installer.

Sat Jun 19, 2021 1:02 am

Note: I have figured the following issue out. For info only.
Add a folder to the reference at Start Menu before [ProductName]

Hi,

Being a "suit" of projects i would consider it normal that each of those projects would be grouped together especially under the Windows Start Menu. This does not appear to be the case with the example projects attached to the article you referred me to.

I have searched your assets to see if I can find how to do this without luck. No doubt due to my inexperience with AI.

Could you be kind enough to advise me how to have the "satellite" project's Start Menu links grouped in the Windows Start Menu - in your example aip "Suite Installation".

Thank you.

AquaComm
Posts: 13
Joined: Wed May 06, 2020 3:25 am

Re: Designing a Multi-Project Solution installer.

Wed Jun 23, 2021 12:24 am

AquaComm wrote:
Fri Jun 18, 2021 1:37 am
Thank you for pointing this article out for me as well as your recommendations.

One stumbling block I have is that each of the projects that make up the suit have a large number of references to the same dll's. These would add approx 20 meg to each projects aip. Ideally each aip would check for the existence of a dll residing in a common folder and then add it to the GAC. If the dll file was not in the common folder then the aip would download it and process it accordingly.

I'm not certain that in this day and age that download size and disk space usage are of such a major concern but is there some AI mechanism available to me to easily manage these dll's?

I assume that a separate aip could be created for these dll's (and other common data) for which it's aip's "Check for Updates" could be initiated as a prerequisite for each dependent aip ensuring that the dll will be in that common folder.
Has this issue been overlooked. I am hoping to get this suit published sooner rather than later :D

Eusebiu
Posts: 4893
Joined: Wed Nov 14, 2012 2:04 pm

Re: Designing a Multi-Project Solution installer.

Thu Jun 24, 2021 2:33 pm

Hi,
Could you be kind enough to advise me how to have the "satellite" project's Start Menu links grouped in the Windows Start Menu - in your example aip "Suite Installation".
The shortcuts from the Start Menu are always displayed under a single folder, subfolders are not allowed under those folders.

When you add a shortcut under the "Application Shortcut Folder" from the "Files and Folders" page of your project, the path is taken from the "Application shortcut folder" field from the "Install Parameters" page.

If you want to have all the shortcuts grouped under the same folder, you can set the same Publisher name for all the projects in the "Product Details" page and also set the shortcut folder's path to "[ProgramMenuFolder][Manufacturer]".

Or, for example, if you set that path to "[ProgramMenuFolder][Manufacturer]\[ProductName]", the shortcut will be installed to the "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Publisher\Product Name", but it will still be displayed under the Publisher's name in the Start Menu.
One stumbling block I have is that each of the projects that make up the suit have a large number of references to the same dll's. These would add approx 20 meg to each projects aip. Ideally each aip would check for the existence of a dll residing in a common folder and then add it to the GAC. If the dll file was not in the common folder then the aip would download it and process it accordingly.
I'm afraid that I do not fully understand this scenario. Are those DLL files common to all the projects or each project has its own set of DLL files?

The "Merge Module" feature may help you with this. In the "Merge Modules and DLL Registration" thread you can read how the merge modules work.

Best regards,
Eusebiu
Eusebiu Aria - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube

AquaComm
Posts: 13
Joined: Wed May 06, 2020 3:25 am

Re: Designing a Multi-Project Solution installer.

Fri Jun 25, 2021 2:48 am

Eusebiu wrote:
Thu Jun 24, 2021 2:33 pm
Hi,
Could you be kind enough to advise me how to have the "satellite" project's Start Menu links grouped in the Windows Start Menu - in your example aip "Suite Installation".
The shortcuts from the Start Menu are always displayed under a single folder, subfolders are not allowed under those folders.
I have difficulty remembering all the Manufacturers names so I use a 'hard coded' name for my suit that the end user will quickly recognise. I have added the 'sub-folder' and it works on one of the members of the suit of applications. I will assume it works on all of them.
FandF.jpg
FandF.jpg (44.67 KiB) Viewed 4975 times
if.jpg
if.jpg (10.52 KiB) Viewed 4975 times
One stumbling block I have is that each of the projects that make up the suit have a large number of references to the same dll's. These would add approx 20 meg to each projects aip. Ideally each aip would check for the existence of a dll residing in a common folder and then add it to the GAC. If the dll file was not in the common folder then the aip would download it and process it accordingly.

I'm afraid that I do not fully understand this scenario. Are those DLL files common to all the projects or each project has its own set of DLL files?
The six or so projects in the suit all require at least some of the dll's and some projects require almost all the dll's.
The "Merge Module" feature may help you with this. In the "Merge Modules and DLL Registration" thread you can read how the merge modules work.
Thank you. It certainly appears to be what I'm looking for but my original question remains. That is, how do I stop each of the projects in my suit from having to download and install the Merge Module.

There will obviously be the "Suit Installation" project that calls each individual AI installer project in the suit. The "Suit" project will download and install, amongst other data the AI project Merge Module. The Merge Module will then be a prerequisite of each sub-project but of course will not need to be downloaded as the sub-project will detect it's presence (the Merge Module being installed first). How do I instruct the sub-projects to detect the Merge Modules existence and not to download it again.

Keep in mind that the Merge Module will require updating from time-to-time so the sub-projects will need to detect the current Merge Module version number. If necessary the sub-project' installer will then call the Merge Modules Updater to ensure it's been updated to include the new/updated dll associated with the sub-projects own new requirements?

I could write a C# dll to do the above but it seems that the above scenario is likely quite common and should easily be handled by AI itself.

Eusebiu
Posts: 4893
Joined: Wed Nov 14, 2012 2:04 pm

Re: Designing a Multi-Project Solution installer.

Thu Jul 01, 2021 1:07 pm

Hi,
That is, how do I stop each of the projects in my suit from having to download and install the Merge Module.
Please keep in mind that the Merge Module project will create a .msm file that should be added to each of the sub-installers. That merge module will be integrated into those installers, but only one of them will install it, the others will see that it is already installed and will not install it anymore.

The merge module will not be downloaded separately, it will be downloaded with the sub-installers (just like you would add a file to all the installers). So, the size of all the sub-installers will increase with the size of that merge module.

If you want to handle those DLL files separately, you can create a simple MSI package containing only those files and add it as a separate sub-installer. In this case it will only be downloaded and installed once and you can also update it separately.

Let me know if you have other questions.

Best regards,
Eusebiu
Eusebiu Aria - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube

AquaComm
Posts: 13
Joined: Wed May 06, 2020 3:25 am

Re: Designing a Multi-Project Solution installer.

Fri Jul 02, 2021 1:30 am

Eusebiu wrote:
Thu Jul 01, 2021 1:07 pm
If you want to handle those DLL files separately, you can create a simple MSI package containing only those files and add it as a separate sub-installer. In this case it will only be downloaded and installed once and you can also update it separately.
I have spent a considerable amount of time reading your documentation and searching your forum and appreciate you comments.

I agree that this is the best way to go in my circumstances.

Thank you for your help.

Eusebiu
Posts: 4893
Joined: Wed Nov 14, 2012 2:04 pm

Re: Designing a Multi-Project Solution installer.

Wed Jul 07, 2021 12:03 pm

You're welcome. Glad to assist.

Best regards,
Eusebiu
Eusebiu Aria - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube

Return to “Building Installers”