This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Patch trying to Install features it shouldn't.
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 01, 2009
06:41 PM
Patch trying to Install features it shouldn't.
I've got quite the mystery on my hands. Hopefully I can provide enough information, my googling so far has yet to net anything useful:
Project Type: Basic MSI
Test Host: Windows Server 2003 SP2, MSI 4.5
I am creating a Patch from version 4.3.x of my product to 4.4.0.[incrementing build number not important since it's in the 4th place].
So far, everything has been fine, except the following:
If I install only a subset of my features to a server, then run the patch -- those features only seem to be updated, which is as one would expect.
However, if I tell the MSI engine to log (i've tried i, *v, and voicewarmup), it seem to start installing all sorts of new files that belong to features that should not exist on this machine.
Here is the first thing in the log that caught me by surprise:
[code]
MSI (c) (84:A8) [15:59:16:741]: PROPERTY CHANGE: Adding REINSTALL property. Its value is 'FeatureCommon,FeatureA'.
MSI (c) (84:A8) [15:59:16:741]: PROPERTY CHANGE: Adding ADDLOCAL property. Its value is 'FeatureB, FeatureC, FeatureD,FeatureASubFeature1,FeatureASubFeature2'.
[/CODE]
it makes sense to me that FeatureA's 'new' subfeatures are selected, as they are required bits of FeatureA, but I can't figure out why FeatureB,C,D are being added to the ADDLOCAL property. Their files start to appear, but all sorts of things with my installers break, as those features aren't supposed to be on this machine, so none of their prerequisites/etc exist and things eventually fail.
Here's another tidbit from my log that confuses me:
[code]
Action start 16:12:49: InstallValidate.
MSI (s) (9C:34) [16:12:49:179]: Feature: FeatureASubFeature1; Installed: Absent; Request: Local; Action: Local
MSI (s) (9C:34) [16:12:49:179]: Feature: FeatureB; Installed: Absent; Request: Local; Action: Local
MSI (s) (9C:34) [16:12:49:179]: Feature: FeatureC; Installed: Absent; Request: Local; Action: Local
MSI (s) (9C:34) [16:12:49:179]: Feature: FeatureD; Installed: Absent; Request: Local; Action: Local
MSI (s) (9C:34) [16:12:49:179]: Feature: FeatureA; Installed: Local; Request: Reinstall; Action: Reinstall
MSI (s) (9C:34) [16:12:49:179]: Feature: FeatureASubFeature2; Installed: Absent; Request: Local; Action: Local
[/code]
If I am patching, and Features-B-D are all Installed: Absent, why the heck are they all of a sudden Request/Action: Local???
I am now performing the same test, but instead of using the command line to log, I am using the registry. please see next post as the results are very confusing.
Project Type: Basic MSI
Test Host: Windows Server 2003 SP2, MSI 4.5
I am creating a Patch from version 4.3.x of my product to 4.4.0.[incrementing build number not important since it's in the 4th place].
So far, everything has been fine, except the following:
If I install only a subset of my features to a server, then run the patch -- those features only seem to be updated, which is as one would expect.
However, if I tell the MSI engine to log (i've tried i, *v, and voicewarmup), it seem to start installing all sorts of new files that belong to features that should not exist on this machine.
Here is the first thing in the log that caught me by surprise:
[code]
MSI (c) (84:A8) [15:59:16:741]: PROPERTY CHANGE: Adding REINSTALL property. Its value is 'FeatureCommon,FeatureA'.
MSI (c) (84:A8) [15:59:16:741]: PROPERTY CHANGE: Adding ADDLOCAL property. Its value is 'FeatureB, FeatureC, FeatureD,FeatureASubFeature1,FeatureASubFeature2'.
[/CODE]
it makes sense to me that FeatureA's 'new' subfeatures are selected, as they are required bits of FeatureA, but I can't figure out why FeatureB,C,D are being added to the ADDLOCAL property. Their files start to appear, but all sorts of things with my installers break, as those features aren't supposed to be on this machine, so none of their prerequisites/etc exist and things eventually fail.
Here's another tidbit from my log that confuses me:
[code]
Action start 16:12:49: InstallValidate.
MSI (s) (9C:34) [16:12:49:179]: Feature: FeatureASubFeature1; Installed: Absent; Request: Local; Action: Local
MSI (s) (9C:34) [16:12:49:179]: Feature: FeatureB; Installed: Absent; Request: Local; Action: Local
MSI (s) (9C:34) [16:12:49:179]: Feature: FeatureC; Installed: Absent; Request: Local; Action: Local
MSI (s) (9C:34) [16:12:49:179]: Feature: FeatureD; Installed: Absent; Request: Local; Action: Local
MSI (s) (9C:34) [16:12:49:179]: Feature: FeatureA; Installed: Local; Request: Reinstall; Action: Reinstall
MSI (s) (9C:34) [16:12:49:179]: Feature: FeatureASubFeature2; Installed: Absent; Request: Local; Action: Local
[/code]
If I am patching, and Features-B-D are all Installed: Absent, why the heck are they all of a sudden Request/Action: Local???
I am now performing the same test, but instead of using the command line to log, I am using the registry. please see next post as the results are very confusing.
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 01, 2009
06:47 PM
Ok, same test, using the registry to perform logging:
Properties of ADDLOCAL/REINSTALL (note the order is different from last time)
[code]
MSI (s) (A8:F4) [16:21:27:403]: PROPERTY CHANGE: Adding ADDLOCAL property. Its value is 'FeatureASubFeature1,FeatureASubFeature2'.
MSI (s) (A8:F4) [16:21:27:403]: PROPERTY CHANGE: Adding REINSTALL property. Its value is 'FeatureCommon,FeatureA'.
[/code]
That makes perfect sense to me, FeatureA and FeatureCommon are already installed, so they are in REINSTALL mode, and the subfeatures are added.
The next bit from above also reflects this, all of the features except Common and A are Installed:Absent and Null for Request/Action -- except the new subfeatures which are Request/Action: Local.
Basically, the patch works perfectly if NO logging is done, or if logging is done by the registry, but the second I use the command line to log, all hell breaks loose.
I'm now trying to hunt down an older VM snapshot with a 3.x copy of MSI.
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Reg_SZ: Logging
Value: voicewarmup
Properties of ADDLOCAL/REINSTALL (note the order is different from last time)
[code]
MSI (s) (A8:F4) [16:21:27:403]: PROPERTY CHANGE: Adding ADDLOCAL property. Its value is 'FeatureASubFeature1,FeatureASubFeature2'.
MSI (s) (A8:F4) [16:21:27:403]: PROPERTY CHANGE: Adding REINSTALL property. Its value is 'FeatureCommon,FeatureA'.
[/code]
That makes perfect sense to me, FeatureA and FeatureCommon are already installed, so they are in REINSTALL mode, and the subfeatures are added.
The next bit from above also reflects this, all of the features except Common and A are Installed:Absent and Null for Request/Action -- except the new subfeatures which are Request/Action: Local.
Basically, the patch works perfectly if NO logging is done, or if logging is done by the registry, but the second I use the command line to log, all hell breaks loose.
I'm now trying to hunt down an older VM snapshot with a 3.x copy of MSI.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 02, 2009
10:31 AM
Same results, Server 2003 R2 SP2 and Windows Installer 3.01. argh.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 02, 2009
03:47 PM
After thoroughly examining the logs, I think I found the problem (and a workaround).
My Update.exe is configured to supply the MSI with the following command line arguments:
I guess I had assumed (and I thought previous builds had) that when I use the /V parameter to the Update.exe it would be adding anything I send in addition to the required 2 parameters above.
I assumed wrongly. Rather than "hope" my users don't utilize MSI logging (which I have our field engineers use religiously), I just created two custom actions that set those properties based on the PATCH condition, so that I can enforce their existence. I understand I probably could have just added it to the direct editor, but it gives me a bit of comfort to be able to see these custom actions in my list, and I'm better able to audit the change.
Finally, using the registry method of telling the MSI engine to log apparently didn't do anything to modify the command line, so that's why that install continued to work.
My Update.exe is configured to supply the MSI with the following command line arguments:
REINSTALLMODE=omus and REINSTALL=ALL
I guess I had assumed (and I thought previous builds had) that when I use the /V parameter to the Update.exe it would be adding anything I send in addition to the required 2 parameters above.
I assumed wrongly. Rather than "hope" my users don't utilize MSI logging (which I have our field engineers use religiously), I just created two custom actions that set those properties based on the PATCH condition, so that I can enforce their existence. I understand I probably could have just added it to the direct editor, but it gives me a bit of comfort to be able to see these custom actions in my list, and I'm better able to audit the change.
Finally, using the registry method of telling the MSI engine to log apparently didn't do anything to modify the command line, so that's why that install continued to work.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)