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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
Sent: Thursday, October 11, 2007 1:28 PM
To: Wilson, Phil; wix-users@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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Painter
Sent: Thursday, October 11, 2007 7:16 AM
To: Peter Bergmann; wix-users@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 <[EMAIL PROTECTED]> wrote:
... right, just checked it. Well, that really sucks ;(
-------- Original-Nachricht --------
> Datum: Thu, 11 Oct 2007 06:20:23 -0700 (PDT)
> Von: Christopher Painter
> An: Peter Bergmann , wix-users@lists.sourceforge.net
> 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
>
>
> Peter Bergmann wrote:
> 6599 is also too early - SxS is not ready yet at this point.
>
> But I've solved it now as proposed by you and Rob using:
>
>
> ...
>
>
> ...
>
>
>
>
>
> 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.
> >
> > 2007/10/11, Peter Bergmann :
> > >
> > > nope ... that did not work.
> > > If I force StartServices directly after install finalize either using
> > orca
> > > or using "Sequence=..." the install process terminats with error code
> > 2762
> > > in the very end ... whatever that means ...
> > >
> > >
> > > -------- Original-Nachricht --------
> > > > Datum: Thu, 11 Oct 2007 13:08:55 +0200
> > > > Von: "János Brezniczky"
>
> > > > An: "Peter Bergmann"
> > > > CC: wix-users@lists.sourceforge.net
> > > > 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
> > > > Orca.
> > > >
> > > >
> > > > 2007/10/11, Peter Bergmann :
> > > > >
> > > > > I'm writing an installer that installs a service which depends on
> > the
> > > > > VC2005 runtime libraries. I'm including the runtime's .msm files
> > using
> > > > > and which works just fine.
> > > > > However at the time when the StartServices action gets triggered
> the
> > > SxS
> > > > > stuff 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
> > > > > install and ScheduleReboot after InstallFinalize. After the reboot
> > the
> > > > > service starts fine automatically. But a reboot is not acceptable
> > for
> > > > this
> > > > > product :(
> > > > >
> > > > > Is there a way to schedule the StartServices action after
> > > > InstallFinalize
> > > > > ?
> > > > >
> > > > > If not - Could I include the vcredist_x86.exe binary into my
> > installer
> > > > and
> > > > > run 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
> WiX-users@lists.sourceforge.net
> 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-users@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-users@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. -------------------------------------------------------------------------
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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
