[wix-users] Fwd: WiX Error Handling
Todd Hoatson
todd.hoatson at gmail.com
Mon Jan 14 13:10:27 PST 2019
Hi Edwin,
thanks for your reply. I looked at the diagram, but I didn't really
understand it. (It seems I'm not the only one...) I don't really think my
problem has to do with the "flow of execution" in MSI, but rather the
inability to communicate back from the custom action to the rest of the
installer code...
Todd Hoatson
On Fri, Jan 11, 2019 at 5:38 PM Edwin Castro <egcastr at gmail.com> wrote:
> What Nick says about setting properties in custom actions (native and
> managed) is true for immediate custom actions as they run in the client
> process. The important detail missing is that deferred custom actions
> cannot set properties that are visible to other deferred custom actions
> (due to sandboxing) or immediate custom actions (due to how the Windows
> Installer manages client vs server processes).
>
> I find the "Saw Tooth" diagram helpful in understanding the flow of
> execution in MSI:
>
>
> https://blogs.msdn.microsoft.com/rflaming/2006/09/21/uac-in-msi-notes-the-saw-tooth-diagram/
>
> --
> Edwin G. Castro
>
>
> On Fri, Jan 11, 2019 at 3:35 PM Todd Hoatson via wix-users <
> wix-users at lists.wixtoolset.org> wrote:
>
>> Thanks, all, for the quick responses...
>>
>> > Your custom action is running on the server side and sets the Property
>> there. When the Windows Installer returns to the client side, the Property
>> is the client side value.
>>
>> That's interesting, because the log shows:
>>
>> MSI (s) (0C!4C) [10:55:58:092]: PROPERTY CHANGE: Modifying ERRMSG
>> property.
>> Its current value is 'Undetermined Error'. Its new value: 'Problem
>> encountered while closing the application'.
>> CustomAction CloseApplications returned actual error code 1603 (note this
>> may not be 100% accurate if translation happened inside sandbox)
>> …
>> Property(S): ERRMSG = Problem encountered while closing the application
>>
>> This would seem to indicate that the value of ERRMSG had been retained
>> after the custom action had ended...
>> (Also, please note that the custom actions in our installer do not run
>> asynchronously.)
>>
>> > Secure Properties can travel from the client to the server but IIRC
>> Properties do not travel back. You
>> > could try marking the Property Secure and see if my memory in wrong and
>> see if Properties can travel back.
>>
>> > I expect there is some communication between the process running your
>> CloseApplications custom action
>> > and the server process but the data from the server process is not
>> getting communicated back to the client
>> > process which is responsible for your UI. My recollection matches Rob's
>> in that communicating a property
>> > from the server process back to the client process is not allowed but
>> you
>> could try making the property
>> > secure just in case our recollection is wrong.
>>
>> This was not what I understood from reading WiX 3.6: A Developer's Guide
>> to
>> Windows Installer XML:
>>
>> "Setting properties is just as easy. You'll set the value by
>> referencing the key with the name of
>> your property. Here's an example:
>>
>> [CustomAction]
>> public static ActionResult CustomAction1(Session session)
>> {
>> session["MY_PROPERTY"] = "abc";
>> return ActionResult.Success;
>> }
>>
>> If the property doesn't exist when you set it, it will be created.
>> Similarly, you can clear a property
>> by settings its value to null. Creating or changing property values
>> from a custom action doesn't
>> stop the installer from displaying those properties in the install
>> log. ..."
>>
>> Nick Ramirez doesn't say that properties set in custom action code written
>> in C# can't be communicated back to the main process (what you have
>> referred to as a "client" process). There didn't seem to be anything
>> there
>> to indicate that something special needs to be done to get the change in
>> value recognized by the main process.
>>
>> So it would seem that Nick Ramirez' book is lacking an important detail
>> here.
>>
>> I searched to book to see how to mark a property as "secure". There I
>> read
>> the following:
>>
>> "Windows Installer may mark the installation as restricted. This
>> means
>> that the properties
>> you set could be ignored. The following scenarios may set this in
>> motion:
>>
>> The user performing the install is not an administrator
>> The install is marked as per-machine instead of per-user, meaning
>> the
>> ALLUSERS property
>> is set to 1 in your markup or the Package element's InstallScope
>> attribute is set to perMachine
>> ..."
>>
>> Our installer (for whatever reason) does indeed have InstallScope set to
>> perMachine. So I changed the property declaration to:
>>
>> <Property Id="ERRMSG" Value="Undetermined Error" Secure="yes" />
>>
>> However, there was *no change* in the installer behavior.
>>
>> In the book I read:
>>
>> "You can tell when you need to use the Secure attribute if, in the
>> install log, you see that the
>> RestrictedUserControl property has been set automatically. You'll
>> also see some of your
>> properties, if they're used in the execute sequence, being ignored.
>> The following is a sample
>> log of that happening:
>>
>> MSI (s) (C8:BC) [23:49:58:906]:
>> Machine policy value 'EnableUserControl' is 0
>> MSI (s) (C8:BC) [23:49:58:906]: PROPERTY CHANGE:
>> Adding RestrictedUserControl property. Its value is '1'.
>> MSI (s) (C8:BC) [23:49:58:906]:
>> Ignoring disallowed property MYPROPERTY
>>
>> I don't see anything like this in the log file...
>>
>> thanks,
>> Todd
>>
>> On Fri, Jan 11, 2019 at 12:34 PM Edwin Castro <egcastr at gmail.com> wrote:
>>
>> > There are many processes involved in an MSI installation. There is a
>> > client process that detects and makes decisions on what to do. The
>> client
>> > process is the one responsible for running the InstallUISequence which
>> > drives your UI dialogs. There is also a server process that is
>> responsible
>> > for making changes to your system. The server process runs standard
>> > actions. There are also one or more processes used to execute custom
>> > actions. These processes are sandboxed from the main client and server
>> > processes so that issues with custom actions do not affect the main
>> > installation sequence. I expect there is some communication between the
>> > process running your CloseApplications custom action and the server
>> process
>> > but the data from the server process is not getting communicated back to
>> > the client process which is responsible for your UI. My recollection
>> > matches Rob's in that communicating a property from the server process
>> back
>> > to the client process is not allowed but you could try making the
>> property
>> > secure just in case our recollection is wrong.
>> >
>> > --
>> > Edwin G. Castro
>> >
>> >
>> > On Fri, Jan 11, 2019 at 10:25 AM Todd Hoatson via wix-users <
>> > wix-users at lists.wixtoolset.org> wrote:
>> >
>> >> Further Details:
>> >>
>> >> In my WiX code (near the top, below the Product, Package & Upgrade
>> tags) I
>> >> have the following property initialization:
>> >>
>> >> <Property Id="ERRMSG" Value="Undetermined Error" />
>> >>
>> >> Then, within my custom action (in C#), I have these lines (as mentioned
>> >> previously) to force a failure:
>> >>
>> >> session["ERRMSG"] = "Problem encountered while closing the
>> >> application";
>> >> return ActionResult.Failure;
>> >>
>> >> In the log file produced by my installer I see the following:
>> >>
>> >> ...
>> >> MSI (s) (0C!4C) [10:55:58:092]: PROPERTY CHANGE: Modifying ERRMSG
>> >> property.
>> >> Its current value is 'Undetermined Error'. Its new value: 'Problem
>> >> encountered while closing the application'.
>> >> CustomAction CloseApplications returned actual error code 1603 (note
>> this
>> >> may not be 100% accurate if translation happened inside sandbox)
>> >> …
>> >> Property(S): ERRMSG = Problem encountered while closing the application
>> >> …
>> >> MSI (c) (24:58) [10:55:58:133]: Doing action: FatalErrorDlg
>> >> Action 10:55:58: FatalErrorDlg.
>> >> Action start 10:55:58: FatalErrorDlg.
>> >> Action 10:55:58: FatalErrorDlg. Dialog created
>> >> Action ended 10:56:23: FatalErrorDlg. Return value 2.
>> >> Action ended 10:56:23: INSTALL. Return value 3.
>> >> MSI (c) (24:58) [10:56:23:082]: Destroying RemoteAPI object.
>> >> MSI (c) (24:50) [10:56:23:082]: Custom Action Manager thread ending.
>> >> …
>> >> Property(C): ERRMSG = Undetermined Error
>> >> …
>> >>
>> >> From this I see that the property has been properly initialized prior
>> to
>> >> it's modification in the custom action. After the custom action has
>> >> returned to the WiX code, the property still has the updated value.
>> Then
>> >> the FatalErrorDlg is activated and closes. But after that the property
>> >> appears to be initialized again to the generic message!
>> >>
>> >> 1. Why is the property being initialized twice?
>> >>
>> >> 2. FatalErrorDlg shows the generic message, "Undetermined Error",
>> rather
>> >> than the updated message, "Problem encountered while closing the
>> >> application".
>> >> Why is this happening? What can I do about it?
>> >>
>> >> thanks
>> >> Todd Hoatson
>> >>
>> >> ____________________________________________________________________
>> >> WiX Toolset Users Mailing List provided by FireGiant
>> >> http://www.firegiant.com/
>> >
>> >
>>
>> --
>> Todd Hoatson
>> Mobile: 763-291-3312
>> Email: todd.hoatson at gmail.com
>> www.linkedin.com/in/toddhoatson
>>
>> ____________________________________________________________________
>> WiX Toolset Users Mailing List provided by FireGiant
>> http://www.firegiant.com/
>
>
--
Todd Hoatson
Mobile: 763-291-3312
Email: todd.hoatson at gmail.com
www.linkedin.com/in/toddhoatson
More information about the wix-users
mailing list