Filter applications from Restart Manager

[Arno]

Hello,

I am installing an add-in DLL that may be in use by PowerPoint 2007.
In Vista, the default behavior for the Restart Manager is to shut down
and then restart PowerPoint. Instead, to minimize user impact, I want
to run the install, then do the unloading/reloading of the add-in
myself. But for other processes that may also use the file, I want the
default Restart Manager behavior.

So I would like to selectively remove Office programs from the Restart
Manager list (or set them to RmNoShutdown).

I tried writing a custom action that runs before InstallValidate and
does RmJoinSession. But RmGetList or RmAddFilter return
ERROR_SESSION_CREDENTIAL_CONFLICT: "This function is only available to
primary installers", presumably because of the RmJoinSession. How is
this supposed to work?

Thanks for help,

Arno

[Phil Wilson]

I don't think you can change that behavior just for PowerPoint without
changing it for everything. PPT has registered with RM so it shuts down and
restarts. An app that doesn't register with RM can't restore itself with
saved state. You can make particular MSI files behave differently with the
new MSI properties like MSIRESTARTMANAGERCONTROL and MSIRMSHUTDOWN, but I'm
pretty sure you can't pick and choose how PPT behaves for a specific
configuration. Besides, the point of this IS to minimize user impact, the
assumption being that the file in use situation will otherwise require a a
reboot, and in terms of impact a short PPT break is better than a reboot.
--
Phil Wilson
[MVP Windows Installer]

"Arno" <asch...@think-cell.com> wrote in message
news:1192986639.8...@y27g2000pre.googlegroups.com...

[Arno]

> You can make particular MSI files behave differently with the
> new MSI properties like MSIRESTARTMANAGERCONTROL and MSIRMSHUTDOWN, but I'm

That's what I am doing now, and it works except that is affects all
applications holding locks.

> pretty sure you can't pick and choose how PPT behaves for a specific
> configuration. Besides, the point of this IS to minimize user impact, the
> assumption being that the file in use situation will otherwise require a a
> reboot, and in terms of impact a short PPT break is better than a reboot.

But reloading the add-in without shutting down PowerPoint is even
better. It is a pity that Microsoft thinks it has the only and true
solution to this problem.

Arno

[Phil Wilson]

I don't know what PPT APIs there are in the programming model, but for all I
know perhaps you can reload the add-in proggrammatically. You're getting
into this situation because you're replacing an in-use file. If you changed
the filename of your add-in, it might be easy to call the PPT APIs to unload
the old one and add the new one.
--
Phil Wilson
[Microsoft MVP-Windows Installer]

"Arno" <asch...@think-cell.com> wrote in message

news:1193146029....@e34g2000pro.googlegroups.com...

[Arno]

I can easily replace the add-in while PowerPoint is running by simply
replacing the DLL and then unloading and reloading the add-in (which
frees the old DLL and then loads the new DLL of the same name). I am
doing this when the installation is done, so the user can keep working
during the installation. The problem is that although a DLL can be
replaced while it is loaded, I cannot get Installer to allow it
without invoking the whole "file-in-use" machinery first.

Arno

[Phil Wilson]

My point is that a custom action to unload the add-in early in the install
would eliminate the file-in-use situation in the same way that you do it
manually, assuming the PPT object model has methods to do that.

--
Phil Wilson
[Microsoft MVP-Windows Installer]
"Arno" <asch...@think-cell.com> wrote in message

news:1193154906.3...@e9g2000prf.googlegroups.com...