Problem with Custom Actions + Suite with MSI projects + Major Upgrade

[#1]

Hello!

I have an InstallShield Suite Project which contains two MSI projects - 32-bit and 64-bit Windows Explorer plugins.
There are DLLs in these projects which I need to register both as a user and as an admin.
I'm using Custom Actions for that. They are launching regsvr32 with the path of the DLL.

The only condition it fails is when I'm doing a major upgrade. Even if there is no condition for the action (so it should run all the time).
And it happens only when I'm using the Suite project. If I run MSI separately it will work even for the Major Upgrade.
So I have the impression that the Suite wrapper is somehow messing with the MSI's upgrade mechanism.

Please help.
Our options for the moment (all of them fix the problem, but are not elegant):

• to disable the upgrade, ask the user to remove the old version manually
  
• not to use the Suite, provide 2 MSI packages separately
  
• ask the user to run the Repair command in the Suite project after the installation, if DLL registration fails
  

Once again:

• MSI is inside the Suite
  
• This is a Major Upgrade
  
• We have Custom Actions like
  Deferred: regsvr32 "[INSTALLDIR]SomeLib.dll" /s
  Condition: REMOVE<>"ALL"
  Deferred in system context: regsvr32 "[INSTALLDIR]SomeLib.dll" /s
  Condition: REMOVE<>"ALL"
  (same libraries get registered with and without the system context)
  

Result: MSI in the Suite project is not registering the DLLs during the Upgrade. I don't get any error during the installation.

[DLee65]

Have you created a log file?
What is the command line passed to your MSI? How does it vary from running the MSI separately?

I have done major upgrades with our suite package but have not encountered any problems.

Command Line: SuiteSetup.exe /debuglog"C:\InstallShield.log" /log"C:\"

Make sure you have enabled logging for the MSI packages in your suite package configuration.
Is the registration process associated with a component? If so did the component get upgraded? I know you said this works when running MSI separately, but I am just trying to think outside of the box here. I too would have expected the same behavior when running separately and when included in the suite package.

[#3]

DLee65 wrote:
Have you created a log file?

Yes, today I've made a lot of logs.
One of them is a log of a Major Upgrade made by MSI inside Suite Project (which has a problem).
The other one is log of a Major Upgrade of a separate MSI package. (which is OK)
And it looks like the first one is running as an admin from the beginning, which is not correct.

I'm looking at the paths returned by SHELL32::SHGetFolderPath.
Separate MSI package has paths of the User.
Suite's MSI package has paths of the Admin.

That's weird. I thought that Suite Project basically just extracts & launches the msi, without elevation. Like if you are launching the msi yourself.
If I switch off "Require Elevated Privileges" in the Packages section of Suite Project, I'll get a error message "msi requires elevated privileges" in the middle of installation and it rolls back.
But it works anyway (with "Require Elevated Privileges" set to yes) if there is NO Major Upgrade happening, even with the Suite Project. This is very strange.
It's like the Major Upgrade in Suite Project forces elevated privileges.
The command line is empty in all cases. I'm not passing any extra parameters.
OS is Windows 7, 32-bit.

[MichaelU]

Suites will typically run the MSI projects already elevated, similar to launching an elevated command prompt and then running msiexec /i the.msi, so that you don't have to accept a separate UAC prompt for each included package. This can change the user context in question for the "deferred (but not in system context)" action such that a different HKCU (or different filesystem paths, like you saw) could be involved.

Of course, as a matter of principle I have to recommend against such self-registration actions. 🙂