2

Creating a Basic MSI install in InstallShield 2015, we are deploying files into a directory created by another Basic MSI installer, which we also created. I'm not sure if that piece of information is relevant or what other variables I'm not thinking of might be relevant. But this works fine for a new install, and delivers all the files into that directory that we want there. But after upgrading the other install and then trying to upgrade this install, it's not delivering any updated files for some reason I can't explain (and the files all do have newer versions), and the log isn't helping much. I'm most concerned with the file PublishRS.exe. This is the first occurrence of that in the log:

Action 11:48:16: InstallValidate. Validating install
Action start 11:48:16: InstallValidate.
01]: Note: 1: 2205 2:  3: Shortcut 
MSI (s) (40:08) [11:48:16:201]: Note: 1: 2205 2:  3: Class 
MSI (s) (40:08) [11:48:16:201]: Note: 1: 2205 2:  3: TypeLib 
 (40:08) [11:48:16:200]: Feature: RSST; Installed: Local;   Request: Local;   Action: Local
MSI (s) (40:08) [11:48:16:200]: Component: PublishRS.exe; Installed: Local;   Request: Null;   Action: Null
MSI (s) (40:08) [11:48:16:200]: Component: FSReportService.asmx; Installed: Local;   Request: Null;   Action: Null

The only other references to that file in the log are when it tried to execute it later on and fails due to the file not having been updated.

Can anyone help explain how I can go about determining why PublishRS.exe was not copied? I think it has something to do with the Request: Null. The thing that's really troubling and unhelpful is that normally the log will say why it's not copying the file, like, the file already exists and doesn't have an older version or something, but here I've got nothing. So most of the explanations about why it wouldn't copy go out the window. After reading Msiexec REINSTALL=ALL REINSTALLMODE=vamus not reinstalling anything I did check that we had not changed any components, and confirmed it. So I'm stumped. What could be causing Request: Null for this component (the component is included in the RSST feature whose Request is Local) on an upgrade installation?

Edit: Bad/old log at https://www.evernote.com/shard/s269/sh/a193db0f-df06-4bd1-bf49-bca83d12e979/1f825266b645077517cb68d2e159cc67 -- do not review this log except to compare to old comments. It is not a representation of the actual problem process.

MSIENFORCEUPGRADECOMPONENTRULES had no effect, and is included in this log.

Edit 2: I've discovered the install works fine in repair mode. I think there may be something I'm not understanding about upgrade. Why would an upgrade treat components differently than a repair? What is an upgrade/update as far as MSI is concerned? Is it not the same as a repair with newer files?

Edit 3: It seems the log I provided earlier may not be the best example. I have a more pure log that shows that the command line does include IS_MINOR_UPGRADE. Sorry for the confusion. Please look at this log and not the one mentioned earlier: https://www.evernote.com/shard/s269/sh/222a67cb-f237-49fb-88f3-1f882f9d762c/5cb19f1c7b86b344299ebf2c6c29ab89

Community
  • 1
  • 1
BlueMonkMN
  • 25,079
  • 9
  • 80
  • 146
  • 1
    I'd post the entire log somewhere. I'd also set MSIENFORCEUPGRADECOMPONENTRULES to 1 to double check that the component rules haven't been broken. Also be sure that same files are delivered to the same location with the same component guid in both products, wasn't clear that's the case in your post – PhilDW Jun 16 '16 at 18:31
  • The log is not of an install. e.g. it says "Skipping RemoveExistingProducts action: current configuration is maintenance mode or an uninstall" and "Component: PublishRS.exe; Installed: Local; Request: Null; Action: Null" means that the component is already installed, the operation is maintenance "do nothing" so the action is null. The MSI is not doing an upgrade, implying that the ProductCode has not been changed and there is major upgrade logic in place. – PhilDW Jun 17 '16 at 17:01
  • @PhilDW That's what I thought too, but the upgrade dialog was presented, so why is it telling me that it's going to do an upgrade, and endign up just doing maintenance mode? This might be tied up with InstallShield and not just MSI. I have a feeling it has something to do with the fact that it also forgot the value of INSTALLDIR and is resetting it from a default location to the correct location during the install. – BlueMonkMN Jun 17 '16 at 17:03
  • Yes, looks like you have an InstallShield mis-configuration somewhere. – PhilDW Jun 17 '16 at 17:16
  • The main issue is likely to be that the ProductCode of the new MSI is the same as one that already is installed on the system. – PhilDW Jun 17 '16 at 17:45
  • @PhilDW Of course, that's what causes an upgrade. We're upgrading a product that's already installed to a new version. I've verified that the **PackageCode** is different on each MSI file, but that the **ProductCode** is the same, and I think that's what it needs to be. – BlueMonkMN Jun 17 '16 at 17:50

2 Answers2

1

It seems that fiddling with the UI sequence can have disastrous consequences. We needed to prompt for some information during the upgrade, and I believe that by including one of our dialogs which had been designed to flow well in the setup and maintenance sequences in the "SetupResume" sequence too, which I believe is what is used on an upgrade, we caused InstallShield dialogs to be pulled into the upgrade sequence that were not designed to be part of that sequence, which forced the install back into the wrong mode instead of an upgrade. One of the InstallShield dialogs was calling AddLocal, which should probably not be happening on an upgrade, for example.

BlueMonkMN
  • 25,079
  • 9
  • 80
  • 146
0

The log is not of an install. e.g. it says "Skipping RemoveExistingProducts action: current configuration is maintenance mode or an uninstall" and "Component: PublishRS.exe; Installed: Local; Request: Null; Action: Null" means that the component is already installed, the operation is maintenance "do nothing" so the action is null. The MSI is not doing an upgrade, implying that the ProductCode has not been changed and there is major upgrade logic in place.

It's not clear from the post if you intend a Windows Installer major upgrade, but if so then the new MSI must have a new ProductCode, the same UpgradeCode, a version that's incremented in the first three digits and FindRelatedProducts and RemoveExistingProducts sequenced in the MSI file.

You may be thinking of minor updates that reinstall the altered MSI with the same ProductCode (and incremented version) but that requires a command line install that includes REINSTALL=ALL REINSTALLMODE=vomus (and vamus is not recommended). However InstallShield seems to be controlling how the underlying MSI is being installed so it's also not clear what type of update it thinks it's doing or what the ultimate command InstallShiel supplies, but the indications and use of the word "upgrade" implies it's a major upgrade.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • I ran InstallShield's upgrade validation and it indicated that a SMALL update would be performed. So why does this look so much like something else? BTW, I found the MSI runs fine if I extract and run it manually with the same command line reported in the log. – BlueMonkMN Jun 18 '16 at 18:15
  • In a newer log from a purer environment (posted in edit 3) I saw that it does include `IS_MINOR_UPGRADE=1` on the command line implying that even InstallShield believes it is performing an upgrade, but... it just doesn't stick for some reason? I see later on it says `Ignoring disallowed property IS_MINOR_UPGRADE` – BlueMonkMN Jun 18 '16 at 20:27