Builds for 32/64 bit

[hsc]

Hi,

I want to create separate installers for the 32 and 64 bit versions of my application, but I want to keep them in a common AI project and use separate builds for each bitness. The 32 bit installer should contain (and install) the file app32.exe, and the 64 bit installer should contain app64.exe. Merge modules should also differ, but several other files like "readme" and "change.log" should not. Is this possible? I saw that I can set the "package type" separately for each build, but I didn't find a way to mark the exe files as "32 only" or "64 only". Maybe I should use separate "features" for each bitness?

Thanks
Hans

[Catalin]

Hello Hans,

You are indeed right!

You can create a build for each bitness.

Additionally, you can set the files in different features and then separate them in the "Organization" page:

Screenshot_116.png (6.45 KiB) Viewed 11258 times

Hope this helps!

Best regards,
Catalin

[hsc]

Hello Catalin, thanks, that did help. By the way, can I do this kind of magic also with AI projects that create merge modules? Like, create the 32- and 64-bit msm files in one project? I didn't find the "Builds" page in the msm project, just a "Build" page which appears to have a different function.

I guess it is not possible to create an msm file and then use it to create an installer in the same project.

How to make prerequisites depend on the bitnes? (64-bit vs. 32-bit MSVC redistributables)

Hans

[Catalin]

Hello Hans,

Glad to hear that helped!

Regarding the MSM, I'm afraid that might not be possible.

Regarding the prerequisites, if you add them as "feature-based", you will have a feature for each in the "Organization" page.

And that feature, you can set to install only in the 32-bit version or 64-bit version of your build, as we did before.

Best regards,
Catalin

[hsc]

Hello Catalin, thanks again. Now that I have separate setups for the 32 and the 64 bit build, I ran unto two more problems:
- The "Name" (under Product Details") is the same for both bitnesses. Since this name is displayed when the setup starts, it is somewhat confusing. I'd like to include something like "32 bit" or "64 bit" in the name.
- Both bitnesses share the same product IDs, so it is not possible to install the 32-bit product and the 64-bit product at the same time.

You you give a solution here too?

Thanks in advance
Hans

[Catalin]

Hello Hans,

- The "Name" (under Product Details") is the same for both bitnesses. Since this name is displayed when the setup starts, it is somewhat confusing. I'd like to include something like "32 bit" or "64 bit" in the name.

In order to achieve this, we can proceed as it follows:

- "Properties" page, create a new property named "MyBitness"

Screenshot_122.png (16.36 KiB) Viewed 10374 times

Screenshot_123.png (17.51 KiB) Viewed 10374 times

As you can see, this property has different value depending on the build.

Now, in the "Product Details" page, we can simply add it to our "Name" field, like this:

Code: Select all

Your Application [|MyBitness]

This way, if you launch the 64-bit version, the correct bitness should be displayed.

- Both bitnesses share the same product IDs, so it is not possible to install the 32-bit product and the 64-bit product at the same time.

Regarding this, indeed they will share the same ProductID. Could you please let me know why you'd like to allow the installation of both on the same machine?

Best regards,
Catalin

[hsc]

Hi Catalin,

thanks for the help, I didn't have the time to try it yet but will for sure.

You asked

Could you please let me know why you'd like to allow the installation of both on the same machine?

The 64-bit application does not yet have the full functionality of the 32-bit app (because we don't have 64-bit replacements for some 3rd party DLLs), and we want customers to use the 64-bit app and give us feedback, but they should be able to switch back to 32 bits if they need some function which is not yet available.

Hans

[Catalin]

Hello Hans,

To achieve what you need, we might need to have different UpgradeCodes for the two builds - basically they will be treated like different apps on the OS.

Below you will find how we can achieve this using our PowerShell automation support:

Code: Select all

$advInst = New-Object -ComObject AdvancedInstaller
​
$project = $advInst.LoadProject("C:\PowerShell Automation\MultipleBuilds\DemoMultipleBuilds.aip")
​
# set UpgradeCode to be used by Release build
$project.ProductDetails.UpgradeCode.UpgradeCode = {F537B3C1-ECA3-4908-A986-002916B25DE7}
​
# build only Release 
$project.Build(Release)
​
​
# set UpgradeCode to be used by QA build
$project.ProductDetails.UpgradeCode.UpgradeCode = {B22206D5-F553-49E0-9F30-E2D9DEEFBA3D}
​
# build only QA 
$project.Build(QA)
​
​
# set UpgradeCode to be used by DEV build
$project.ProductDetails.UpgradeCode.UpgradeCode = {D9D3CE69-CA91-40C6-9B7F-28497F35A751}
​
# build only Dev 
$project.Build(Dev)

As you can see, in the example we have 3 builds for which we will have separate UpgradeCodes.

Hope this helps!

Best regards,
Catalin

[hsc]

Hi Catalin, this is really interesting. I didn't know I could use AI as a COM object. I will have to explore this further - it might simplify many tasks. Until now, I have maintained separate *.aip files for each upgrade code. I found the documentation at https://www.advancedinstaller.com/user- ... ation.html and will read it throughly.

Thank you!
Hans

[Catalin]

You are always welcome, Hans!

Regarding the separate AIP files, if you want you can use the "Save as template" option and have one AIP file for each build.

This would ,however, discard the multiple build approach we've taken so far.

Best regards,
Catalin