Building a new installer

[Zsolt Kollarits]

Dear Advanced Installer Support Team,

We have a 32-bit/64-bit mixed setup wizard that we developer for years now. I will send it over via email. Now it's time for use to create a purely 64-bit installer as all of our resource file are 64-bit only.

Could you please take a look at the .aip file I'll forward to you and give us some recommendation about how would you do it. We are looking for the best way to go on, it does not have to be the easiest.

There are 2 options in our head:
1. Creating a brand new installer from scratch and try to copy over all of our existing customization (custom actions, registry keys, searches etc.) into the new project
2. We would keep the current .aip and would try to remove all of our 32-bit resources (including the belonging registry keys) from it.

When checking our .aip, please focus on the registry area too, that part is quite "messy", so that is kind of the weakest point of our setup, so our decision is also based on what you propose in order to "modernize" our registry keys.

Also we are wondering what is your opinion about creating a brand new setup by using the MSI/MSIX technology?

So in general, could you please share your thoughts about your recommendations?

Thanks in advance.

Best regards,
Zsolt

[Catalin]

Hello Zsolt,

Since you want to start a new project but have as a base your current project, I would suggest the "Save as Template" option.

Here's another article which I've written that highlights the benefits and the headache we can avoid by using this option: Efficient Project Duplication with Advanced Installer's 'Save as Template' Feature

Could you please take a look at the .aip file I'll forward to you and give us some recommendation about how would you do it. We are looking for the best way to go on, it does not have to be the easiest.

There are 2 options in our head:
1. Creating a brand new installer from scratch and try to copy over all of our existing customization (custom actions, registry keys, searches etc.) into the new project
2. We would keep the current .aip and would try to remove all of our 32-bit resources (including the belonging registry keys) from it.

How I would do it is that I would remove all the 32-bit components (files, registry entries, even some custom actions perhaps) and save the project as a template and then start a new project based on the template.

However, this would be seen as an entire new project and therefore MSI/EXE, which means that if your clients already have installed the setup, this new setup will appear as "duplicate" in control panel if the setups will have the exact same name.

Honestly, your second approach doesn't seem all that bad either - i.e. to get rid of all 32-bit resources from the project and then change the type from mixed package to 64-bit.

My only concern here is a possible upgrade. As I haven't really faced such a scenario, I really can not tell how it'll behave.

Hope this helps!

Best regards,
Catalin

[Zsolt Kollarits]

Dear Catalin,

Thank you very much for your answer. I will read more about your "Save as Template" feature, and probably will come back to you.

Moreover we had an internal discussion and it would be pretty important for us that our customers should be able to perform a normal upgrade from an older version of our product (the older 32-bit/64-bit mixed versions) to the new, future version (purely 64-bit) of it, so we would like to avoid having side-by-side versions in Control Panel/Components and Features.
Do you have a suggestion for that one, how should we handle this? I think this requirement might affect the way we should go on.

Also what would be the benefits using MSI/MSIX technology over the current MSI/EXE technology? Would you recommend to go for MSIX?

Thanks.

Best regards,
Zsolt

[Catalin]

Hello Zsolt,

I've given better thought to this and I've come up with the following:

So basically the mixed package contains two packages, one 32-bit and one 64-bit which are installed based on the OS bitness.

The chances that you have many 32-bit packages installed are really low, I would guess, considering PCs have gone from 32-bit to 64-bit OS long ago.

Moreover we had an internal discussion and it would be pretty important for us that our customers should be able to perform a normal upgrade from an older version of our product (the older 32-bit/64-bit mixed versions) to the new, future version (purely 64-bit) of it, so we would like to avoid having side-by-side versions in Control Panel/Components and Features.
Do you have a suggestion for that one, how should we handle this? I think this requirement might affect the way we should go on.

Now, since you have mentioned that you would like the 64-bit package to upgrade the mixed one, there are two possible cases:

- the 32 bit package on a 32 bit machine --> nothing we can do here as your 64-bit package will not be able to install on a 32-bit machine (only a 32-bit can be installed on a 64-bit, not the other way around)

- the 64-bit package --> here, your new 64-bit package should upgrade just fine considering the previous version is also 64-bit.

That being said, I think we would be pretty safe with one of the approaches you previously mentioned - to remove all 32-bit resources and then simply change the package type to 64-bit from "Install Parameters" page.

Note: if you decide to change the guids for the components, that would work similarly with the "Save as Template" (except that one also changes the UpgradeCode so basically the newer product will be seen by Windows as a "brand new" one).

I think this would be the best approach, especially because you do not want double entries in the Control Panel and more custom configurations.

Also what would be the benefits using MSI/MSIX technology over the current MSI/EXE technology? Would you recommend to go for MSIX?

I will be honest with you here, I do not recommend MSIX for complex projects such as yours. When time permits, you can give it a try, but I'm not sure MSIX supports many custom things you have in your project.

Regarding MSI, you could try building an MSI if:

- you do not need fancy UI (e.g. only use the themes specified under "Classic" in the "Themes" page)

- do not need prerequisites installed before the main package

- do not need the "Run as administrator" option

One big advantage of MSI is the native integration with tools such as Intune, SCCM, etc..

Hope this helps!

Best regards,
Catalin