Installing products side-by-side for testing purpose

[Zsolt Kollarits]

Dear Advanced Installer,

We would like to allow our partners to install multiple (2) versions of the our product in parallel. Thus, if they have e.g. v.34 installed and start the v.35 setup they should have a chance to install v.35 into a different folder and then use both versions.

What would this mean from a setup point of view?

We know that there are technical issues especially with COM – this will be further analyzed by developers. But how difficult would it be for you to handle the setup part?
- The new setup should be default behave as today -> upgrade
- There should be some trick how a user can trigger a side-by-side installation of multiple versions. How exactly? Any ideas? E.g. the user has to set a registry value and then the setup would always install into program files\Therefore\v.35 -> multiple versions can be installed side-by-side; or would we ship special setups which allow side-by-side installation?
- Any other problems with shared resources like COM? We suppose we can just register one DLLs with the same name into HKeyClassesRoot. Are there more topics than just COM registration? What else would be overwritten if we install a second version of the client?
- Start menu: we need multiple entries there. One folder per version.


What is your opinion on this? Installing 2 versions of the same product? Our goal is to install the newer version of our product for testing purposes only, temporarily, and have it next to our old product. If the test phase is ok, we would like to install the new version as an upgrade, over the old version, so the old version should be gone.

Best regards,
Zsolt

[Zsolt Kollarits]

Hi,

One more question I missed to add:

Could we create one setup, e.g. v.35, and just somehow manipulate the UpgradeCode to create a "test" version of the .exe file? So we would have an official, commercial .exe, with the SAME UpgradeCode as every of our products + we could temporarily create a test exe (but the exact same exe) with a modified UpgradeCode, so that it could be installed side-by-side with our older version.

Best regards,
Zsolt

[Catalin]

Hello Zsolt,

There should be some trick how a user can trigger a side-by-side installation of multiple versions. How exactly? Any ideas? E.g. the user has to set a registry value and then the setup would always install into program files\Therefore\v.35 -> multiple versions can be installed side-by-side; or would we ship special setups which allow side-by-side installation?

If you enable the side-by-side option, a special dialog will be automatically added in your project which will let the user choose whether he wants a side-by-side installation or if he wants the older version removed. This is exactly what we do in Advanced Installer also - not sure if you mentioned but when you install a newer version, if you select "Configure", the side-by-side dialog appears.

The main ideea here is for files to not reside in the same folder, so ideally you should install into a different folder. The easiest way to "automate" this would be to input the ProductVersion into your installation folder. If your APPDIR looks like this:

Code: Select all

[ProgramFilesFolder][Manufacturer]\[ProductName]

We can have the ProductName like this (in the "ProductDetails" page):

Code: Select all

Your Application [|ProductVersion]

What else would be overwritten if we install a second version of the client?

The files will not be overwritten per-se, but the COM registration might be overwritten with the new version of the DLL.

From a dev perspective, I think this article can be useful:

Registration-Free COM Interop

To ensure this works properly, you should test this on a VM before releasing it to the client.

Could we create one setup, e.g. v.35, and just somehow manipulate the UpgradeCode to create a "test" version of the .exe file? So we would have an official, commercial .exe, with the SAME UpgradeCode as every of our products + we could temporarily create a test exe (but the exact same exe) with a modified UpgradeCode, so that it could be installed side-by-side with our older version.

Yes, of course you can do this. If you generate a new UpgradeCode for the test version, the Windows Installer will treat this as a completely separate program and therefore you can easily install them side-by-side. Once again here, the products should be installed in different folders.

Best regards,
Catalin

[Zsolt Kollarits]

Hi Catalin,

I modified our .aip and enabled the "Allow side by side installs of different product versions" checkbox and created version 1.0.0. Then from the same .aip we created a new .exe, version 1.0.1 by using the Generate new option. If we install 1.0.0 on a virtual machine and then we install 1.0.1 over it, how it should behave? For us it behaves as a normal standard upgrade, and replacing 1.0.0 by 1.0.1.

We expected a different behavior if the "Allow side by side..." checkbox is enabled for both 1.0.0 and 1.0.1.

I'll send our .aip in an email for you. Could you please take a look?

Best regards,
Zsolt

[Zsolt Kollarits]

Hi Advanced Installer Team,

This ticket is rather important for us, do you have any updates? I've sent our .aip and my last message 8 days ago.

Thank you!
Zsolt

[Liviu]

Hello Zsolt,

Sorry for the delayed reply on this. My colleague Catalin is out of office and I will further assist you.

I modified our .aip and enabled the "Allow side by side installs of different product versions" checkbox and created version 1.0.0. Then from the same .aip we created a new .exe, version 1.0.1 by using the Generate new option. If we install 1.0.0 on a virtual machine and then we install 1.0.1 over it, how it should behave?

When you enable the option, you are informed that you can add the UpgradeDlg dialog, which allows you to decide during installation whether you want to perform a side-by-side installation or an upgrade.

side by side.png (17.88 KiB) Viewed 2678 times

UpgradeDlg.png (83.25 KiB) Viewed 2678 times

I requested more details and the project file via email.

Best regards,
Liviu