habib at hsalim.com
Mon Nov 4 05:29:34 PST 2019
Thank you so much for a long and thoughtful reply. Ive started reading
Robert Flaming’s blogs. Thanks also for that link.
This is the third version of the installer for Mercury, our reporting
application. In version 2, I looked into the WiX SQL extension and found
that it did not suit my needs. I created my database using custom
In v3, we decided to use Azure SQL databases, hence the need for
PowerShell. I pass in a bunch of parameters that I collect using a custom
UI in the installer and it creates a mostly empty database based on a
template. The database name, server, firewall rules are all managed in
PowerShell (based on parameters). We’ve got this working well (manually).
Although we will not need to write to the database using the installer, I
need to capture a few values that will be stored in a config file. A
connectionstring for example.
Installer rollback on PowerShell failure is what I want.
*From:* Edwin Castro <egcastr at gmail.com>
*Sent:* Monday, November 04, 2019 3:08 AM
*To:* WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
*Cc:* Habib Salim <habib at hsalim.com>
*Subject:* Re: [wix-users] PowerShellWixExtension
I generally discourage database management with the Windows Installer.
There are likely better tools out there. Some of them might be executable
with a Windows Installer custom action. If you really think the Windows
Installer is the tool to use to create/update your database, then have you
considered using the WiX SQL extension,
https://wixtoolset.org/documentation/manual/v3/xsd/sql/ ? For example, you
create your database.
If you are talking about https://github.com/flcdrg/PowerShellWixExtension then
it seems you cannot return any meaningful data. That extension executes
your powershell script files and/or inline scripts in deferred custom
actions. Those custom actions do create a $session variable that you could
use to create properties if and only if your Powershell script was running
immediate. The restriction is one imposed by the Windows Installer engine.
Immediate custom actions can create/modify properties but deferred custom
actions cannot. Deferred custom actions can make system changes but
immediate custom actions cannot. I find
in understanding when various things are executed by the Windows Installer.
The Saw Tooth diagram can be viewed on the wayback machine at
http://flaming.com seems to be down.
In general, with the Windows Installer you need to think declaratively
instead of imperatively. You should make a decision at "immediate-time"
(violet and/or orange regions of the saw tooth diagram) about what the
database name should be and then use that database name in inline scripts
or in an argument to script files which execute at "defer-time" (teal
region of the saw tooth diagram).
The Powershell script file or inline script completes successfully when
there zero non-terminating errors, zero uncaught/unhandled exceptions, and
the exit code reported to the PowerShell host is zero. If there are any
non-terminating errors or any exceptions that are unhandled or the exit
code is set to a non-zero value, then the deferred custom action will fail
and should cause your installation to fail and rollback. So a script
succeeding indicates success. Schedule actions depending on the database
existing after the action that creates it.
Edwin G. Castro
On Sun, Nov 3, 2019 at 9:14 PM Habib Salim via wix-users <
wix-users at lists.wixtoolset.org> wrote:
I need to create a database with my installer and this Powershell extension
I stumbled upon today seems like a perfect for the job.
I want to return a success/failure code and a string containing the
How do I capture these values in a property that I can reference later?
WiX Toolset Users Mailing List provided by FireGiant
More information about the wix-users