Running a Maintenance - Modify (Change) Install From the Command Line?

[Superfreak3]

Hi all,

I'm wondering what the command line would be to force a Modify install. The situation is this... we conditionally place some components, etc based on the presence of a third party app. What happens at times is that users update our software before they update the third party software. After they update the third party software, they can then run a Maintenance - Modify - "Change" install to place the new pieces.

On the Feature selection dialog box, when running through the UI, the said feature is now marked for installation and all works well.

Note: We support several versions of the third party product, so we can't utilize a launch condition because we have no idea what version they may be using/upgrading from.

I'm just wondering if one can run this maintenance install from the command line, or can you only execute a Repair (reinstall all (that were previously installed)) from cmd.

What compounds the problem is that we have another, native 64 bit installer that launches to do the same thing on that Architecture. What I was hoping to do was, from the placing install - detect that we are running a Modify by hashing out the command line. Set a public property indicating we are Modifying. Pass that to the widget that runs that fires the ancillary installer and run that install in maintenance modify mode as well.

Is there any way to

1) launch a modify from the command line that will place the features now seen as needed
2) hash out the command line to determine we are in fact in Maint/Mod mode. ?

Any pointers, direction, help, is GREATLY appreciated!!

[MichaelU]

I think there are a couple intertwined questions here. The simplest is that, for Windows Installer, detecting maintenance internally can be as simple as the condition 'Installed'; requesting maintenance externally can be done via command lines involving the ADDLOCAL or REMOVE (or rarely a few other) properties. InstallScript-based setups are entirely different; you'll need a response file specific to the changes you want to make, unless you've coded up something else interesting.

As far as detecting all this externally, it depends very much on what's doing the detecting. I don't think we offer any specialized primitives for this, but if you're working with the Windows Installer API there are a lot of functions you can look into. For what I think you're describing, I would start with MsiQueryProductState, MsiQueryFeatureState, and/or MsiConfigureFeature.

[Superfreak3]

What I wanted to do was change our update widget to handle a new option, let's say 'Redeploy' If checked the current installation would be rerun in Maintenance mode. I was hoping that if any registry entries are now detected during maintenance, which triggers the installation of involved features all would be good.

What I forgot about is that in the UI, I have some AddLocal actions on one of the dialogs which set the features for installation. I guess I would need to do that on the command line.

So, I guess my changes would be more involved in our update widget. I would not only have to handle any new 'redeployment' option, but would have to query the feature states so that the command line could be adjusted accordingly.

I was hoping that this would be a bit simpler and the current .msi would handle everything just by passing a maintenance command line.

Come to think of it, when we call the x64 .msi to handle this stuff on 64 bit systems, it is called from the widget silently. There is no AddLocal stuff set on the command line. There are AddLocal items from one of the dialogs, but in most cases, this is not hit, seen.

So, maybe it will work with a REINSTALL/REINSTALLMODE command line. I'll double check this with some testing. It's probably false hope and I'll be back to square one as Reinstalls only act on the features that were previously installed and not ADD new ones. Come to think of it, if I install our app before the third party update, initiate a Repair to get our stuff in place, nothing changes - that is why a Modify is needed so back to square one I guess.

And, I guess I'm starting to ramble 😛

[Superfreak3]

I think I have this figured out. I can run my normal command line (/qb! /i) to initiate the silent maintenance install. The action that sets ADDLOCAL is currently sequenced after a few other actions that follow AppSearch in the Execute sequence...

AppSearch
MyAction1
MyOtherAction
SetMntADDLOCAL

.
.
.

Everything seems to hash out OK as the additional features are installed on maintenance. I just want to be sure this is OK sequencing for setting ADDLOCAL (not too early).

When I logged to check ADDLOCAL, I saw that it only contained the new features being installed. I thought it would have a value of the previously installed features + what is being added through maintenance... MyFeat,MyFeat1,MyFeat2,New1,New2. I guess it only holds what is being added locally during the current action alone. ??

Any guidance appreciated!!