Install CustomAction does not run when /PASSIVE passed at command line
livingstone
My MSI includes Install and Uninstall custom actions. This MSI always
gets deployed with /PASSIVE passed in.
My problem is that install custom actions don't always get executed
when running the MSI for the second time (running the MSI after it had
already been installed). Whether install CAs get executed or not seems
to be affected by /PASSIVE parameter passed at command line. I am
looking at these two scenarios:
Scenario #1:
Run the MSI for the second time by double clicking the MSI. Repair/
Remove dialog comes up. Selecting Repair (which happens to be default
button) will result in install CAs execution, as desired.
Scenario #2:
Run the MSI for the second time but this time from the command line:
msiexec /I Something.MSI /PASSIVE
In this scenario my install custom actions are NOT executed. I would
like to change this behavior.
I should mention that install CAs do run OK when executing the MSI for
the second time from the command line without /PASSIVE parameter:
msiexec /I Something.MSI
I have tried tried changing Condition for my Install CA (to force CA's
to run no matter what) to:
NOT Installed OR Installed OR
MaintenanceMode="Repair" (Install CA still didn't run in
scenario #2)
NOT Installed OR Installed OR
MaintenanceMode="Modify" (Install CA still didn't run in
scenario #2)
NOT Installed OR Installed OR MaintenanceMode=?Repair? (this
causes runtime error)
NOT Installed OR Installed OR MaintenanceMode=?Modify? (this
causes runtime error)
I should probably also mention that my MSI has these settings:
DetectNewerInstalledVersion=True
RemovePreviousVersions=True
Any help will be greatly appreciated!
LoZ
Hi,
The problem you have is that in scenario one you're using the UI to
put the MSI into maintenance/repair mode. In scenario two you're
effectively trying to install a product that is already installed.
This won't just not run the CAs, it won't actually do anything.
The question I would have is, why are you trying to install the
application passively over the top of an existing install? Are you
trying to repair? If so you should run the following command line:
msiexec /f <path to msi> /passive
If you want to ensure that the Install CAs run no matter what
(presumably during repair as well?), you should condition them using
REMOVE<>"ALL". This covers off every scenario except uninstall.
Hope this helps.
Cheers,
Loz
Wilson, Phil
the ProductCode guid. That product is already installed, and Visual Studio's
default maintenance mode action is to Repair. So your custom actions won't
run.
--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972
"livingstone" <livingst...@yahoo.com> wrote in message
news:c9093e6e-dddc-4859...@g6g2000vbr.googlegroups.com...
livingstone
there yet". Maybe (most likely) because I don't fully understand /
PASSIVE option and/or difference between running MSI from the command
line vs. interactively-by double clicking the MSI. My understanding
(and I might be wrong) is that /PASSIVE literally takes all default
options to avoid having the user interact. If REPAIR is the default
option when running the MSI by double clicking it for the second time
why wouldn't the II run of the msi from the command line take supposed
default option of REPAIR and actually run custom actions as well?
Also, the second consecutive run of the MSI from the command line
msiexec /I Something.MSI /PASSIVE
msiexec /I Something.MSI /PASSIVE
will actually DO SOMETHING so to some extent I have to disagree with
LoZ that
>> "This won't just not run the CAs, it won't actually do anything. "
If any of the files installed by the first run of the MSI get deleted
(by mistake, for example), running the MSI on top of itself in
Scenario #2 will actually reinstall the missing files - isn't this a
sort of repair?
Maybe I should I ask the question like this: how can I make sure that
CAs will execute on the II consecutive run of
msiexec /I Something.MSI /PASSIVE
LoZ, I tried your suggestion to set condition on my custom actions to
REMOVE<>"ALL" and it didn't help - CAs still don't run in Scenario #2
outlined in my first post.
To answer LoZ's question - the reason I am even trying to test running
MSI on top of itself
msiexec /I Something.MSI /PASSIVE
msiexec /I Something.MSI /PASSIVE
is to have a full understanding of what it does, if anything, in case
my customer ends up doing it. My customer always runs with /PASSIVE
because they push my MSI via SMS at night and the requirement is that
no user interaction is permitted (MSI is sort of silent, userinput-
less install). I needed to know what happens, if anything, if the
customer pushes the same MSI by mistake two times in a row. Now that I
discovered what it does I am trying to make the second run of the
msiexec /I Something.MSI /PASSIVE
do the exact same thing that the first run did. Maybe I am chasing my
tail?
Thanks again folks.
Cheers,
livingstone
LoZ
Hi livingstone,
The behaviour you see during a second installation (msiexec.exe /i) is
entirely by design. The thing to bear in mind is that Windows
Installer is aware that the product you are installing has already
been installed and registered on the machine. In UI mode (/passive not
used) Windows Installer offers the user the chance to say "whoops,
wrong command line" and choose to repair or modify (REINSTALL property
gets set) instead.
In non- or basic-UI modes (/passive, /quiet) Windows Installer just
sees that the product is registered and effectively does nothing. This
is expected behaviour. It's being run non-interactively so there is no
user sitting there to tell it what they ACTUALLY meant to do.
I work for a big company using SCCM to deploy MSIs and can assure you
that this is the behaviour that I see when an advertisement is re-run
on a machine. It fires the same command line (msiexec.exe /i <msi
path> /quiet) and Windows Installer kicks in to handle checking
whether the product is already installed.
I may not have communicated it very well but I was not expecting that
conditioning a CA using REMOVE<>"ALL" would run under your scenario
#2. But it is exactly the condition you would use to ensure that the
CA fired in every valid execution mode (install, repair/reinstall) and
not when the product was being uninstalled.
Hope this clears it up a bit.
Cheers,
Loz
Wilson, Phil
try to install it again. You'll see a maint dialog as LoZ mentioned. The
default is Repair. It does not install it "again", whatever that might be
thought to mean. When you run without showing UI all that happens is that it
takes that default and does the repair. It's not even looking at your MSI
file, it's using the cached one in Windows\Installer.
--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972
"livingstone" <livingst...@yahoo.com> wrote in message
news:80ab6618-1fc3-484e...@j19g2000vbp.googlegroups.com...
LoZ
wrote:
> Forget passive for a moment. Install the MSI file. After it's installed,
> try to install it again. You'll see a maint dialog as LoZ mentioned. The
> default is Repair. It does not install it "again", whatever that might be
> thought to mean. When you run without showing UI all that happens is that it
> takes that default and does the repair. It's not even looking at your MSI
> file, it's using the cached one in Windows\Installer.
>
> --
> Phil Wilson
> The Definitive Guide to Windows Installerhttp://www.apress.com/book/view/1590592972
>
That's not my understanding at all Phil.
In my experience even if the default option offered by the UI window
is repair, using /passive with /i will not do anything at all the
second time round. Windows Installer will not switch into maintenance
mode automatically, it will just see that the product is registered
and stop the install.
It will reference the cached MSI as you say but will not repair it if /
i has been passed in the command line.
Which would explain why in livingstone's scenario #2 described above,
the custom action(s) do not fire again.
Anyway, I could be completely wrong on this but my experiences suggest
otherwise.
livingstone
I agree that cashed version of the MSI will be used the second time
around. I am good with that in all of my scenarios because cashed MSI
is IDENTICAL to the MSI running II time around. I think our our
conversation might be coming down to what REPAIR really means. The way
I see it REPAIR consists of:
A - "replenishing" of any missing files (target files manually deleted
after the first/clean install) and
B - firing of custom actions
When running with UI and selecting REPAIR explicitly, both A and B
happen (I see this as a full repair)
When running from the command line with /I, both A and B happen (I see
this as a full repair)
When running from the command line with /I /PASSIVE, only A happens (I
see this as a partial repair).
LoZ
I was with you up until you said that running from the command line
with /I /passive when the app is already installed puts the missing
files back down. This does not happen in my experience. Running an
advertised shortcut belonging to the app will "self heal" as long as
the missing files are keypaths for components. Broadly speaking.
A lot of what you need to know is held in the logs. Windows Installer
does a great job of logging loads more information than you could
possibly need if you tell it to. At the command line I think the most
verbose option is to tag "/l*xv <path to log>" at the end.