[wix-users] Fwd: WiX Error Handling

[Rob Mensching]

The "(s)" in the log line means server side and I think you've confirmed Properties (even secure ones) don't come back from server.

_____________________________________________________________
 Short replies here. Complete answers over there: http://www.firegiant.com/

-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Todd Hoatson via wix-users
Sent: Friday, January 11, 2019 11:57 AM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Todd Hoatson <todd.hoatson at gmail.com>
Subject: Re: [wix-users] Fwd: WiX Error Handling

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