Why start services before InstallFinalize?
Lon W.
before InstallFinalize in the InstallExecuteSequence table? (Other than
'because StartServices requires it'.) I ask because it seems risky to me
that you would begin running your application before you are technically not
finished with the deferred execution phase of your install.
For reference, here's a portion of the SDK's suggested sequencing:
5800-InstallServices
5900-StartServices <==
6000-RegisterUser
6100-RegisterProduct
6200-PublishComponents
6300-PublishFeatures
6400-PublishProduct
6600-InstallFinalize <==
One example: You sequence RemoveExistingProducts just before
InstallFinalize (a valid sequencing option for RemoveExistingProducts.) In
that case, you would be starting your product's services even before you
begin the uninstallation of the products being upgraded. The risk would be
that the service was probably not designed with the awareness that the
products being upgraded might yet be installed when the service is started.
The following sequencing passes ICE validation, so I would assume this would
at least address the RemoveExistingProducts issue. However, I also wonder if
there is any need/reason that StartServices should occur before the Register*
and Publish* actions?:
5800-InstallServices
6000-RegisterUser
6100-RegisterProduct
6200-PublishComponents
6300-PublishFeatures
6400-PublishProduct
6450-InstallExecute <==
6500-RemoveExistingProducts <==
6550-StartServices <==
6600-InstallFinalize
I would appreciate any thoughts anyone has on this issue, especially since
I've never developed a service myself and might be missing something obvious.
Dennis Bareis
On Fri, 12 Nov 2004 15:19:02 -0800, Lon W. <qwe...@spammenot.com> wrote:
>Is there a good reason why the starting of services should be performed
>before InstallFinalize in the InstallExecuteSequence table?
>I would appreciate any thoughts anyone has on this issue, especially since
>I've never developed a service myself and might be missing something obvious.
If you can't start successfully start the service you may want your install to rollback.
Ordering of actions is obviously important and while some might be valid
(as far as the rules go) some orders will be wrong for any particular requirement.
My 2 cents worth,
Dennis
---
Dennis Bareis [MVP] (dba...@KillSpam.labyrinth.net.au)
http://www.labyrinth.net.au/~dbareis/index.htm
Freeware MSI creation or updating tool (simple and automated):
http://www.labyrinth.net.au/~dbareis/makemsi.htm
Lon W.
I see your point. But in that case, the start routine of the service better
roll-back any changes it made up to the point of failure. Not only that, but
what if 5 services successfully started (and possibly made system changes)
and then the 6th service failed to start? Would the change made by the 5
successfully started services be rolled back?
Another point: .NET global assemblies are not fully installed in the GAC
until the commit phase. This means that if a service requires access to one
of those global assemblies, it shouldn't be started until after
InstallFinalize.
Anyway, the more I think about this issue, the more it makes sense to me
that StartServices would be better placed after InstallFinalize (if it could
execute in immediate mode).
Lon W.
Phil Wilson
marked as waiting for the action to complete in the ServiceControl table.
That's how you tell MSI whether starting the Service is critical to the
install. So you could cause a rollback by failing to respond to the SCM if
you wanted to. When StartServices is before InstallFinalize, this just
works - it's in the audited phase where it can be rolled back.
I wouldn't put StartServices after InstallFinalize because it applies to
Services that you might not actually be installing (this is the
ServiceControl table being processed, not the ServiceInstall table). I'd
start the special Services with a custom action after InstallFinalize, not
by moving StartServices.
--
Phil Wilson [MVP Windows Installer]
----
"Dennis Bareis" <dba...@KillSpam.labyrinth.net.au> wrote in message
news:dhrap0tlh3a84hmc7...@4ax.com...