[wix-users] Fwd: WiX Error Handling

Todd Hoatson todd.hoatson at gmail.com
Fri Jan 11 11:57:15 PST 2019


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



More information about the wix-users mailing list