Zsolt Kollarits
Posts: 346
Joined: Fri May 29, 2015 10:36 am

Building a new installer

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
Posts: 6735
Joined: Wed Jun 13, 2018 7:49 am

Re: Building a new installer

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
Catalin Gheorghe - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube
Zsolt Kollarits
Posts: 346
Joined: Fri May 29, 2015 10:36 am

Re: Building a new installer

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
Posts: 6735
Joined: Wed Jun 13, 2018 7:49 am

Re: Building a new installer

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
Catalin Gheorghe - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube
Zsolt Kollarits
Posts: 346
Joined: Fri May 29, 2015 10:36 am

Re: Building a new installer

Dear Catalin,

Thanks for all the info you have provided so far. Actually I'm just about to start this - relatively big - task of converting our .aip project to be a 64-bit project (not a mixed one).

I've read both your posts once more and I would like to be sure if I understand you correctly: so if we DO NOT want to have duplicate projects under Control Panel / Programs and Features, so we would like to just "continue" our product it means we would like to install our future, pure 64-bit version product over our older mixed 32/64-bit version products, then the only option is to remove the 32-bit components, regkeys and so on and change the project type to be a 64-bit project? Am I correct?

With this requirement the other option, the "save as template" option is a no go for us?

Our biggest concern is that our registry area is pretty messy right now, and that part is something will be hard to clean up. That's the main reason why we wanted to create a new 64-bit project.

Best regards,
Zsolt
Catalin
Posts: 6735
Joined: Wed Jun 13, 2018 7:49 am

Re: Building a new installer

Hello Zsolt,

You are always welcome! :)
I've read both your posts once more and I would like to be sure if I understand you correctly: so if we DO NOT want to have duplicate projects under Control Panel / Programs and Features, so we would like to just "continue" our product it means we would like to install our future, pure 64-bit version product over our older mixed 32/64-bit version products, then the only option is to remove the 32-bit components, regkeys and so on and change the project type to be a 64-bit project? Am I correct?
You are indeed correct here.

However, the only problem I'm seeing here is your 64-bit setup upgrading the 32-bit one. This is something that you guy will have to test out once the project is fully converted to 64-bit.

Since mixed package basically means the 64-bit msi is installed on 64-bit machines and the 32-bit msi is installed on the 32-bit machines, most of your upgrades should be done with no issues. However, we should also test the above case I mentioned to ensure a smooth process for all your customers.

Best regards,
Catalin
Catalin Gheorghe - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube
Zsolt Kollarits
Posts: 346
Joined: Fri May 29, 2015 10:36 am

Re: Building a new installer

Dear Catalin,

Recently I was working on our new purely 64-bit installer by modifying our old "mixed 32/64-bit" installer. However now I started to get an exception when trying to build our project, this is the exception message:

Error calling MSI API: 1627 Method: MsiDatabaseImport Table: FeatureComponents. Extended Error:
Write Table IDT: 1: 2216 2: D:\Product\TheDev64Bit\Setup\Outcome\Server\TheServer.msi 3: FeatureComponents.idt 4: 120 .

Advanced Installer 21.7.1 build 326ab1f5
*** Stack Trace (x86) ***

[0x761898b2] RaiseException()
[0x6f017e86] CxxThrowException()
[0x01d8559f] -----
[0x01d8022e] -----
[0x01e33321] -----
[0x01e33778] -----
[0x01cee7c5] -----
[0x01cf6209] -----
[0x016528a6] -----
[0x0165272e] -----
[0x0165273d] -----
[0x01ceb801] -----
[0x0168ce39] -----
[0x018d2009] -----
[0x015599f7] -----
[0x0123ecbf] -----
[0x010792ae] -----
[0x01f02337] -----
[0x01215d3f] -----
[0x7772be3b] RtlInitializeExceptionChain()
[0x7772bdbf] RtlClearBits()
[0x00bb0000] MODULE_BASE_ADDRESS

Also I see these notifications in the build log:
Notification: The following Localization Identifiers do not have translations:
ActionText.Description.AI_AiRemoveFilesRebootImmediate for languages:1033-English (United States)
ActionText.Template.AI_AiRemoveFilesRebootImmediate for languages:1033-English (United States)
ActionText.Description.AI_AiRemoveFilesRebootDeferred for languages:1033-English (United States)
Property.ProductName for languages:0-Language Neutral
ActionText.Template.AI_AiRemoveFilesRebootDeferred for languages:1033-English (United States)
ActionText.Description.AI_AiRemoveFilesRebootRollback for languages:1033-English (United States)
ActionText.Template.AI_AiRemoveFilesRebootRollback for languages:1033-English (United States)

Do you have any idea what is wrong with our .aip project and how to get rid of that exception? Unfortunately the exception details is not really meaningful.

Thank you.

Best regards,
Zsolt
Liviu
Posts: 1081
Joined: Tue Jul 13, 2021 11:29 am
Contact: Website

Re: Building a new installer

Hello Zsolt,

This looks like a duplicate entry or an invalid name in the Features table - Table Editor page.

Can you please send us the .AIP (setup project) file by email to support at advancedinstaller dot com so we can further test and investigate this?

Best regards,
Liviu
________________________________________
Liviu Sandu - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube

Return to “Building Installers”