2 installs clash

[joealaimo]

Hello,

I am having a problem with 2 different installs that I created for 2 different software are somehow clashing with each other.

I have 2 installs. Let's call them install A and B. If A is installed and then B is installed, it works fine. If B is installed first then A, it does not and just shows the word "error" in a dialog box. At some point in the install log it says that it is starting the action "FindRelatedProducts". Within that section it shows this message "Using cached product context: User non-assigned for product: 819E279D219E7649BF22BBD90660C23". This large ID # seems to be the key to the problem. The registry has a key with this ID as it's name. Within this key is the ProductName property and it is showing the name of installer B. When it is removed, the installer works. When it is there, it does not. The key is in HKCU\software\microsoft\installer\products.

I have found the following topic from 10 years ago with the same problem but a solution was never posted:
viewtopic.php?f=2&t=6363

Can the solution to this issue be posted?

Thank You

[FrancescoT]

Are you sure that each setup project uses its own and unique ProductCode?

[joealaimo]

Hi Francesco,

Yes. Each install uses it's own product code.

Install A - {02F27612-24AA-4BCC-9B3A-E4EA8EA082A6}
Install B - {D972E918-4912-467E-B92F-B2DB0966C032}

Does the installer take any information from the machine that creates the installer (like the UUID)? Both installs were created on the same laptop. Should I install installaware on a different laptop and then create one of the two installers from that new laptop?

Thanks

[FrancescoT]

No, the installer doesn't take any information from the building machine, and you don't have to use two different machines to build the packages.

I suspect there is something wrong or not properly done with the projects.

Do these projects have something in common as; target folders, files, components or else?

Can you share the entire log file of the failing installation?

[joealaimo]

Attached is the entire log.

The only things that these installers share is the installation of 3 common files that will not be overwritten if they exist already. However, these 3 files are housed in different source folders so the source files are different for each installer but their installation destination is the same. They also install some of the same pre-requesites like .NET and SQL Server local DB drivers. But even these files are housed in different source folders.

A few things to note inside of the log file:

1, Line 833: "Using cached product context: User non-assigned for product: 819E279D2194E7649BF22BBD90660C23".
This seems to be linked to the problem. This GUID is listed in the registry as a folder under "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Installer\Products". The information in this registry folder is linked to Install B (ie the product name is that of install B). When running install A, the error occurs. However, if I rename this registry folder (for example add an x at the end), then install A runs without problem.

2. Line 853: This shows the errors that occur.

Thank you.

Joe

[FrancescoT]

The setup process failed due Error 1603.

Most of the cases (if not all), error code 1603 indicates that a file or a component is being held in use by another process. Due of this, I suggest you to verify if your installer is trying to install/uninstall "something" which seems to be currently in use.

Unfortunately the Windows Installer log doesn't indicate which component is causing the issue.

Hope this helps you.

[joealaimo]

Hi Francesco,

If it was the case that it is trying to install something that is already in use then why would it work when I change the registry folder name from 819E279D2194E7649BF22BBD90660C23 to 819E279D2194E7649BF22BBD90660C23xx? Changing that registry folder name would not affect what is currently running if that was the case.

I think that the problem is due to the installer using this product entry when it should not and therefore it thinks that product A is now product B and then it finds a conflict. Can you tell me how and when the installer adds a product entry to this registry location and why product A cannot find its own entry at this location?

Thank you

Joe

[FrancescoT]

If it's as you are saying, this means that both installers are sharing the same product code...otherwise, I canoot explain the behaviour you described.

Do you have any chance to send me a minimal version of those projects?

[joealaimo]

Hi Francesco,

I don't have a minimal version of those projects but I can take the task of scaling them back to create them. I will post something as soon as I have it. It will most likely be tested and ready by next week.

Thanks

Joe

[joealaimo]

Hi Francesco,

I have created 2 minimal installs that exhibit the problem. They are called InstallTest1 and InstallTest2. They both install just one file each, the application exe. I did not include that exe but you can rename any exe in its place such as cmd.exe. The 2 installs have no direct relation to each other.

When the installs are run, they create an entry into the registry under HKCU\Software\Microsoft\Installer\products. The entry is a large GUID. These GUID entries seem to be important, as I will mention below.The GUIDs for these installs are:

InstallTest1: 21672F20AA42CCB4B9A34EAEE80A286A
InstallTest2: 819E279D2194E7649BF22BBD90660C23

When I run InstallTest1 and then InstallTest2, I do not encounter any problems. However, if I run InstallTest2 and then InstallTest1, I receive an error when running InstallTest1 (I have also attached the log for when this happens). The registry GUID entry for installTest1 seems to be linked to the issue. If I alter the GUID before I run InstallTest2 (such as add a 'xyz' to the end), then I do not get the error. That is why I do not think that it is a file conflict.

Please let me know if you need anything else.

Thank you

Joe

[FrancescoT]

Both your projects are sharing the same identical "UPGRADE CODE".

upgrade_code.png (17.05 KiB) Viewed 5512 times

To fix the issue, I assigned a "new and unique" upgrade code to "InstallTest1 Project".
(Ex.{2668A222-C724-4C50-9BB4-3506A79CEE95}).

One additional note, both projects also share an identical installation folder (Create Folder $MYAPPDATA$\FLFPPR).
This may be a problem if both installers store files under such location.

Hope this helps you.

[joealaimo]

Hi Francesco,

Thank you for finding this. This change did fix the problem. I had overlooked the upgrade code because I thought that this only applied to patches. Since we were not doing patches, I did not realize that this field was being used.

All the best.

Joe