I agree, not much disagreement. The way I look at it though is that InstallFinalize doesn't really do anything other then execute script generated by something else. For example if I wrote and scheduled a commit CA that did something ( good or bad ) it might be being done inside InstallFinalize as part of the commit execution but in a sense it's not really being done by InstallFinalize, it's really being done by script generated by MsiPublishAssemblies.
Who knows... maybe I'm making too fine of a point in trying to distinguish between the host and the script but I think you know what I'm trying to say. Perhaps if one was to look at the MSI source code we would find that the lines of responsibility aren't so clearly drawn for `standard` actions.
Regardless I think it's a horrible implementation that continues to cause developer confusion.
"Wilson, Phil" <***@wonderware.com> wrote:
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} I dont think theres much disagreement here. As I (and the documentation) said, its InstallFinalize that does the commit, and I wasnt referring to any of the other things that are associated with the term commit. I specifically mean that InstallFinalize is where fusion gets called to commit assemblies (to the GAC and to SxS on Vista for the CRT and other C++ support Dlls). MsiPublishAssemblies does more than my characterization, but it seemed to me that people might get the idea from your comment that MsiPublishAssemblies is what commits assemblies.
Phil Wilson
From: Christopher Painter [mailto:***@yahoo.com]
Sent: Thursday, October 11, 2007 1:28 PM
To: Wilson, Phil; wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Starting service after InstallFinalze
If you read Stefan's article ( which I'm sure you have ) commit execution is really for cleaning up rollback information and isn't even run when rollback is disabled by policy. Seing how MsiPublishAssemblies is a `Standard` action instead of a Custom action I'm sure that it gets around this limitation.
I would argue that MsiPublishAssemblies is really the source of the race condition not InstallFinalize ( InstallFinalize just does what it's been told to do during script generation phase).
MsiPublishAssemblies should really be telling Installfinalize to install to the GAC during the deferred execution so that when StartServices is scheduled afterwords it will work. However Microsoft said that there was a problem with trying to rollback GAC changes so they designed it to be commit and hence the problems we see here.
http://www.installsite.org/pages/en/isnews/200108/index.htm
AFAIK MsiPublishAssemblies does more then you suggest based on the MsIAssemblyName table help topic:
"If there is at least one entry in the MsiAssembly Table, the InstallExecuteSequence Table must contain the MsiPublishAssemblies Action, and MsiUnpublishAssemblies Action.
Because assemblies cannot be rolled back after they are committed, Windows Installer uses a two-step installation process. The interfaces to the assemblies are created during the installation operations that are generated by the MsiPublishAssemblies Action.
The assemblies are not committed until successful execution of the InstallFinalize Action. This means that if you author a custom action or resource that relies on the assembly, it must be sequenced after the InstallFinalize Action. For example, if you need to start a service that depends on an assembly in the Global Assembly Cache (GAC), you must schedule the starting of that service after the InstallFinalize Action. This means you cannot use the ServiceControl Table to start the service, instead you must use a custom action that is sequenced after InstallFinalize."
"Wilson, Phil" <***@wonderware.com> wrote:
Its not MsiPublishAssemblies, just in case someone is tempted to try moving StartServices so that its after MsiPublishAssemblies but before InstallFinalize. Its InstallFinalize where the commit actions take place, including the GAC assemblies.
AFAIK MsiPublishAssemblies mainly takes care of dependencies between assemblies for example if you install a GAC assembly and a client with a dependency on it, MsiPublishAssemblies is what adds the client reference so you cant delete the assembly from the GAC.
Phil Wilson
From: wix-users-***@lists.sourceforge.net [mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Christopher Painter
Sent: Thursday, October 11, 2007 7:16 AM
To: Peter Bergmann; wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Starting service after InstallFinalze
Sorry. I'm sure there was some really good reason why they wrote MsiPublishAssemblies that way ( I don't buy the rollback reason.... getting it to work at all is more important then getting it to rollback IMO ), but it really stinks since installing in the Commit phase doesn't match the expected behavior of installing in the deferred phase.
All you can really do is
1) Install as prereq to eliminate the race condition
2) Don't rely on the WinSXS/GAC ( private assembly or statically link )
3) Don't try to start the service .. insist on a reboot instead
4) Don't rely on the assembly ... somehow use reflection / late binding to start the service with minimal functionality and then light up the rest when the assembly becomes available.
Maybe there are some other patterns that I'm missing....
--
Chris http://blog.deploymentengineering.com
Peter Bergmann <***@gmx.net> wrote:
... right, just checked it. Well, that really sucks ;(
-------- Original-Nachricht --------
Datum: Thu, 11 Oct 2007 06:20:23 -0700 (PDT)
Von: Christopher Painter
Betreff: Re: [WiX-users] Starting service after InstallFinalze
I'm afraid that you haven't really solved it An immeadiate CA scheduled
after InstallFinalize won't have the needed permissions to start the service
in scenarios like UAC/Limited User and Elevated/Managed installations.
I would personally bite the bullet and get a bootstrapper together to
lay the prereq down so that ServiceStartService will function as designed
without the need for a CA. The real problem here is the Assembly Publishing
/ Merge Module story, not the SCM story.
--
Chris http://blog.deploymentengineering.com
6599 is also too early - SxS is not ready yet at this point.
...
...
Many Thanks!
However I'm still wondering what the "official" way is to start up a
service that needs access to the included VC2005 distributable runtime libraries
... ?
Cheers,
Peter
-------- Original-Nachricht --------
Datum: Thu, 11 Oct 2007 13:58:06 +0200
Von: "János Brezniczky"
An: "Peter Bergmann"
Betreff: Re: [WiX-users] Starting service after InstallFinalze
Try that with before installfinalize (6599 or so).. it seems like the
installation script which this operation should have been written to has
already run.
Post by Peter Bergmannnope ... that did not work.
If I force StartServices directly after install finalize either using
orca
Post by Peter Bergmannor using "Sequence=..." the install process terminats with error code
2762
Post by Peter Bergmannin the very end ... whatever that means ...
-------- Original-Nachricht --------
Datum: Thu, 11 Oct 2007 13:08:55 +0200
Von: "János Brezniczky"
An: "Peter Bergmann"
Betreff: Re: [WiX-users] Starting service after InstallFinalze
Sounds evident, if I'm not wrong... the answer is in your letter.
Have you tried sequencing it with installexecutesequence (and
adminexecutesequence)?
I mean adding
It should work as an override.
A typical value for enter_a_sequence_number_big_enough_here could be
anything > 6600, e.g. 6700 should be fine, since InstallFinalize
typically
has a default sequence of 6600. This latter value can be checked
using
Post by Peter BergmannOrca.
Post by Peter BergmannI'm writing an installer that installs a service which depends on
the
Post by Peter BergmannPost by Peter BergmannVC2005 runtime libraries. I'm including the runtime's .msm files
using
Post by Peter BergmannPost by Peter Bergmannand which works just fine.
However at the time when the StartServices action gets triggered
the
Post by Peter BergmannSxS
Post by Peter Bergmannstuff obviously is not yet in place and my service fails to start.
The only solution I came up with is to not start the service
during
Post by Peter BergmannPost by Peter Bergmanninstall and ScheduleReboot after InstallFinalize. After the reboot
the
Post by Peter BergmannPost by Peter Bergmannservice starts fine automatically. But a reboot is not acceptable
for
Post by Peter Bergmannthis
Post by Peter Bergmannproduct :(
Is there a way to schedule the StartServices action after
InstallFinalize
Post by Peter Bergmann?
If not - Could I include the vcredist_x86.exe binary into my
installer
Post by Peter Bergmannand
Post by Peter Bergmannrun it automatically first ? How would I do that?
Many Thanks for any hints!
Cheers,
Peter
--
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users
---------------------------------
Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get
listings, and more!
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
---------------------------------
Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
---------------------------------
Yahoo! oneSearch: Finally, mobile search that gives answers, not web links.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
---------------------------------
Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.