Launching/Detecting Maintenance Install From Command Line...
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. ?
Answers (3)
Contition your feature/component with 'If Installed'. It's not on the command line, of course, but if you want to nanny your users, you need to make your installation bullet-proof. If it was me, I'd be detecting the installed state in, say, a script compiled to an EXE and either prevent your software being updated without the presence of the correct versions of the support files or run the installation for those files as a pre-requisite.
you want to be able to just run it after the install.
It sounds like you could just run the msi again:
msiexec /I app.msi
That would recognise that it was already installed and go through a repair, depending on the property settings as already mentioned. But this would leave the users having to go through the dialogue and making sure the correct features are installed.
You could run, to be a bit cleverer,
msiexec /fchoose you combination...
msiexec /fomus GUID ADDLOCAL=NameoftheFeatureYouwanttoADD /QB
That would suit your situation better, it sounds like the MSI has something that detects something that you are eluding to being there, but if you add the name of the feature(s) they will be added and you can do it silently....
Comments:
-
First, our install in most cases runs silently. Going through the UI works fine as is. I'm currently thinking that our update widget would have to determine the feature states and set ADDLOCAL accordingly. Can I just do that via Custom Action after AppSearch runs if a Maintenance install is run? - Superfreak3 9 years ago
-
I guess the question is, when is ADDLOCAL set and will it be recognized if reset during a maintenance install? - Superfreak3 9 years ago
-
Also, with the /f options, they only deal with features/files that have already been installed, correct? I don't know that they will have any bearing on placing additional features/files during Maintenance. For those familiar with InstallShield Basic .msi projects, with maintenance I mean _IsMaintenance="Change" (Modify option on the maintenance type dialog). - Superfreak3 9 years ago
-
/f yep, kind of, but you can also add or remove features. To do just a maintenance, no repair, run msiexec /I ProductCode ADDLOCAL=feat1,Feature6. You can also remove features, or add one and remove another - Badger 9 years ago
-
ok, what is your update widget??? - Badger 9 years ago
-
Our update widget basically looks at an ini value on a Server and compares to an ini value on the Client and if Server > Client = update ready. The widget just fires msiexec /I path to new .msi. My thinking is that the code in that widget would have to use the windows install api/objects to check the installation and/hash out the registry triggers and set ADDLOCAL. I would rather not do that because we are hoping to phase out the widget in the near future. I was hoping that I could do it all in the .msi.
The only change we would make to the widget is to add a redeploy option. If selected, a different command line, if needed, would launch the .msi.
Our current command line is /I /qb! our.msi. If relaunching with that command line would work, along with a Custom Action to set ADDLOCAL after AppSearch - property set is run (If Installed), that would be cool. - Superfreak3 9 years ago -
Have you looked inside the MSI?? you were saying that when the update comes users add a feature. I think you need to stare outside for a bit then focus on this. If an MSI is installed, you can repair it (by Rclick) if you launch the MSI again, it detects that is installed, and go into maintenance mode, either a repair or the dialogue allowing changes or removal. I think that widget just runs the MSI it knows about, there must be upgrade info in there. More than likely there is a condition on the features we are talking about here. They will look for the existence of an Feature in the MSI. I would recommend using a custom action to change the addlocal property. Its making my head hurt thinking about it. How many different scenarios might you need to this app?? - Badger 9 years ago
-
Yes, there are conditions on the Features, which I would like to hash out via custom action after AppSearch in the Execute Sequence. Believe me when I say, my head hurts too. We certainly don't do things the easy way, and it is cumbersome. My alternative is to install everything for everyone, which I don't particularly like, but I don't know that the powers that be care all that much. - Superfreak3 9 years ago
-
so, hash out??? what does that mean. To understand what they do, or to remove them? If there are conditions, just leave them. It sounds like its doing what you want. When the MSI is installing, repairing or doing maintenance, its checking the feature conditions. If you use the command to run with ADDLOCAL that should over power (win) with the condition of the feature, it would be easy to test. So you can force the install to add the Features you want, right at the beginning and you would be done. - Badger 9 years ago
-
I just whipped up a quick test installer that first only installed one feature. I run the same install from the same /I only install command line. There is a custom action that sets ADDLOCAL to Feat1,Feat2. The other feature was installed as hoped!!!
I think I'll just create a custom action to grab the properties set from the registry entries and set the ADDLOCAL prop accordingly. This will only run with the condition" Installed AND NOT REMOVAL="ALL" AND UILevel <> 5. So far, the results look promising. - Superfreak3 9 years ago -
When you say use ADDLOCAL on the command line, that would mean I would have to grab the registry entries and set ADDLOCAL from the update widget instead of within the .msi itself. What I've been trying seems to work using the same, initial command line. Install runs through and the custom action runs and sets addlocal. - Superfreak3 9 years ago
-
Sorry, just had someone ranting about their project..
registry entries... no no no, just the name of the feature, from the feature table. I was also just thinking about the custom actions, its a shame they are using CustomActions, they should just use the condition table, much easier. You might have to have a play with overwriting the CA. At least the conditions they have on the CA are OK. So, on a clean machine, just the features you select will be installed, then after its installed, on a repair on maintenance but NOT a Remove, the CA will run, and check for things and set the ADDLOCAL property, which in effect turns a feature on. So, on an intial install, you need to set ADDLOCAL= the name of all the features you want, and your done. - Badger 9 years ago -
I wasn't saying use the registry entries for ADDLOCAL if that's what you mean. Currently during AppSearch, reg keys are queried and properties, which server as the Feature conditions, are populated. Reg key/value there - Feature is set to install (InstallLevel adjusted if conditional property populated). I was just saying that if done outside of the .msi, the update widget would have to query the registry entries and use that information to place said features in the ADDLOCAL comma delimited property value. I really don't want to do that so I thought I would just check the property values and set ADDLOCAL with matching feature names via CA to be run only in silent (UILevel<>5) maintenance mode (Installed). Im not sure why it is a shame we are using a Custom Action to do this. The action is not currently in place, that is what I hope to institute. If there is another way to do this without a CA ("they should just use the condition table, much easier") I am not aware. - Superfreak3 9 years ago
-
this is very close to resolved isn't it?? The widget just identifies it needs to install the newer MSI. The MSI you have been playing with seems OK. You are now aware that you can manually invoke the MSI for maintenance to add or remove features. so, warm fuzzy feeling?? - Badger 9 years ago
-
I'm hoping so, yes! There is another layer to this, but I'll leave that unsaid for now! :D - Superfreak3 9 years ago
-
YAY!! and good work on doing the playing with an MSI ADDLOCAL stuff. have fun. Raise that other layer in diff question. - Badger 9 years ago
I don't know that what you are suggesting will solve my problem or issue. Maybe I'm not explaining what is happening sufficiently.
Let's say I have Feature1 and Feature2 as part of my install. Feature2 is installed only after a registry check for a certain version of a third party app sets a conditional PROPERTY. So, for the first step, the user installs our software lacking the specific third party app version. Only Feature1 will be installed in this case.
Now, the user updates the third party app. To get our pieces that correspond with this version in place, a maintenance install must be run selecting Modify. The Feature selection dialog now shows Feature2 as set to be installed and all gets placed as desired.
My question is simply, can I achieve the Modify part of this scenario from the command line.
I was hoping I could, capture the trigger from the command line and pass this through the widget discussed above to run the x64 .msi in maintenance/Modify mode as well.
I think what I might have to do is to check the reinstall properties you mentioned and condition the Feature2 with something like( <Current conditions>) or (<Current conditions> AND <reinstall check>). - Superfreak3 9 years ago
Wouldn't it be a quadzillion times easier to simply prevent any installation if the 3rd-party app is missing? Or prevent selection of the feature that requires it?
You're aware, are you, that you can detect a feature's installed state, too, using the Windows Installer object? http://msdn.microsoft.com/en-us/library/aa369767%28v=vs.85%29.aspx - anonymous_9363 9 years ago
I think for this to work from the command line, I might have to mess with ADDLOCAL if the current feature conditions are met and its a maintenance install, then add the Feature to ADDLOCAL. ??
What the plan was was to update our update widget to add an option to 'Redeploy' which would force a Maintenance from the command line from within the widget. It just might not be that easy I guess.
I'm going to test a bit calling our install from the command line after adding the third part reg entries which serve as the conditional triggers. - Superfreak3 9 years ago
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 (New1,New2) during the current action alone. ??
Any guidance appreciated!! - Superfreak3 9 years ago
You guess correctly! :-) You are "ADDing", after all. The existing features would need to be handled with the REINSTALL and REINSTALLMODE properties. - anonymous_9363 9 years ago