You present a database of how you wish the world to be configured for your
installation. Windows Installer takes that database and creates a script
from it. That script first analyzes which components need what (to be
installed, upgraded, repaired, removed) and then a script is written by
checking the impact of each of the component's resources, then the script is
run (in resource-order, not component-order).
Let me illustrate with a simple-yet-contrived simplistic example:
MSI File:
Component A
File A1
Registry R1
Component B
Registry R2
Registry R3
Component C
File C1
File C2
Registry R4
Imagine that in this example Component B was already installed from another
product, and Component C is upgrading from a previous product installation
(Component A is new).
Windows Installer first determines that Component A and C will be installed,
and B will be left alone. Then it will look to see if any registry entries
need to be removed due to components that are being either installed or
removed, and those get written into the script (none in our example). Then
any files that need to be removed for similar reasons (none in our example).
Then any files that need to be written from components being installed (A1,
C1, & C2), then any registry entries (R4). That is what all of the actions
sequenced between InstallInitialize and InstallFinalize do.
So, the built script for our example will have 4 entries in this order:
Write File A1
Write File C1 - overwriting whatever may have already been there
Write File C2 - overwriting whatever may have already been there
Write Registry R1
Write Registry R4 - overwriting whatever may have already been there
So, there is no moment of installing Component A (with everything in it) vs.
a different moment of installing Component C (with everything in that), for
instance. The conversion from described state to actual state is caused by
this analysis of components (the atomic units of installation) and the
resources connected to those components and is the heart of Windows
Installer's state engine.
It is possible to "send" messages to the UI and/or to the log to show state
(that is how you can get "Installing Files.." or even "Installing
<path-of-file>" messages. In fact, the UI and the logging share the same
code inside the Installer engine, so anything that can be sent to the one
can be sent in a similar way to the other (for the most part). The question
becomes one of when in the script you want it sent.
-----Original Message-----
From: Slide [mailto:slide.o....@gmail.com]
Sent: Wednesday, December 02, 2009 6:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Logging from XML file?
Sorry, I meant my Product.wxs (or any other wix xml source). Generally I
would just like to have something printed to the log if I did:
msiexec /i myinstaller.msi /l* install.log
I would like to do something like this:
<Component Guid="SOME-GUID-HERE">
<Log Level="Info" Message="Installing some
component...MYPROPERTY=[MYPROPERTY]"/>
</Component>
Thanks,
slide
On Wed, Dec 2, 2009 at 6:44 PM, Blair <os...@live.com> wrote:
> Which XML file are you referring to, and what do you want to log that
comes
> from that file?
>
> Off the top of my head I don't know of anything specific, but the answers
> to
> these questions will go a long way to getting you an answer.
>
> -----Original Message-----
> From: Slide [mailto:slide.o....@gmail.com]
> Sent: Wednesday, December 02, 2009 11:15 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Logging from XML file?
>
> Is it possible to log something to the installer log file from the XML
> definition?
>
> Thanks,
>
> slide
>
>
----------------------------------------------------------------------------
> --
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
----------------------------------------------------------------------------
--
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
slide-o-blog
http://slide-o-blog.blogspot.com/
----------------------------------------------------------------------------
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
