[wix-users] Anyone know how to set a property from a powerscript customaction ?
egcastr at gmail.com
Fri Apr 29 21:59:51 PDT 2016
You first talked about powerscript and now you're talking about
powershell. The interwebs indicate they are different things...
In either case, you cannot communicate back to the Windows Installer as
you have already determined.
That said, if you do not need to communicate back to the Windows
Installer *AND* you can guarantee the existence of powershell (or
powerscript) on your target systems, then you can quite easily use a
number of mechanisms to run those scripts by setting up proper command
lines. Checkout this post for some things to consider if you want to
execute powershell scripts from your MSI as custom actions:
Something you'll run into time and time again as you read answers on
stackoverflow, blog posts, online tutorials, forums, mailing list
archives, etc., is that script custom actions are not considered a "best
practice" for many, many reasons. In my opinion, the most important
reason is they are notoriously fragile and difficult to test/debug.
Another reason, often overlooked, is that many anti-virus solutions will
detect and disable script execution causing installers using vbscript,
jscript, and powershell custom actions to fail.
I understand why you would think that a scripting technology will
accelerate your solution as that appears to be the case in most other
types of development but I would caution that acceleration usually comes
at a price, lower quality. When you factor in all the testing required
to ensure solutions are of high quality you don't really see much of a
difference between scripting technologies and compiled technologies.
In the specific case of Windows Installer, you will often pay a large
price with scripting technologies but it is your price to pay. If you
know what you're doing, and don't need to communicate back to the
Windows Installer engine, and you can ensure the scripting engine will
always be available on your target systems, then by all means go ahead
and write your scripts and execute them as custom actions.
If you need to communicate back to the Windows Installer, then you
*MUST* use a C/C++ custom action DLL, a vbscript custom action, a
jscript custom action, or a .NET custom action DLL (typically C# or
VB.NET). You don't really have many other options. Note that the
bridge/shim technology you talk about already exists for these types of
custom action as they've been implemented either by the Windows
Installer itself, or by the WiX toolset. Other Windows Installer
authoring tools might offer other scripting options (I believe you can
interact with the Windows Installer engine with InstallScript if you're
using InstallShield, for example).
If you ever become interested in figuring out what it would take to
develop the "bridge/shim" technology to write powershell custom actions
that can communicate with the Windows Installer engine, then I would
encourage you to read up on implementing a custom powershell host
application. You'd likely write that in C# and it would probably make
most sense to build it on top of WiX's .NET integration. You'd probably
want one or more WiX extensions to allow declarative specifications of
these new types of powershell "custom actions". The custom action would
likely be a "normal" .NET custom action that determines the script to
run embedded in the Binary table, extracting the code and telling the
custom powershell host application to execute the extracted code. The
custom action and custom powershell host application together would be
responsible for providing the appropriate .NET objects so that the
powershell script could interact with the Windows Installer engine in
the same way a .NET custom action, vbscript, or jscript custom action
could. Actually, this could be a fun little project!
Edwin G. Castro
On 4/29/2016 2:03 PM, Gary M wrote:
> Thanks for the reply. Unfortunately, I'm not and cannot using VS for this
> project. I wish I could. I'm trying to resist introducing/enabling
> platform technology that has not been not previously approved. I also need
> to stress the need for scripting language solutions. Introduction of
> compiled/binary artifacts will alter the deployment timeline possibly
> adding 6-9 months to release schedules as a well as increased costs.
> The powershell issue boils down to language libraries, more specifically
> what's shared between the installer's scope and the outboard scripting
> motor. As indicated by Bob A on a stackoverflow thread, Jscript and
> vbScript runs in the installer's runtime context. Conversely, powershell
> and other spawned processes execute in private contexts. This means I
> require a bridge/shim technology between powershell and msi contexts, a new
> project budget I will not be able to get approved. The most timely solution
> is a pivot, discard powershell for these functions and shift to vbScript or
> The wix web site should have a "best practices" section to help educate
> developers new to wix and avoid some of these costly pitfalls. I'm sure I'm
> not the only person bumping into these issues.
> On Fri, Apr 29, 2016 at 7:11 AM, Phill Hogland <phill.hogland at rimage.com>
>> I don't know if (or why it would be) in Power Script. As also indicated
>> later in that thread, it appears to be a DTF C# example. If using Visual
>> Studio and if WiX toolset is installed create a new Windows Installer XML
>> C# Custom Action project and then drop that code over the sample code that
>> Votive created for you. The source with samples and documentation for DTF
>> are in the WiX Toolset source download.
>> From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of
>> Gary M <garym at oedata.com>
>> Sent: Thursday, April 28, 2016 6:44:10 PM
>> To: WiX Toolset Users Mailing List
>> Subject: [wix-users] Anyone know how to set a property from a powerscript
>> customaction ?
>> I was using vbscript for customaction, but I just realized jscript and
>> vbscript are not allowed on these systems.
>> I was using this as a guidance:
>> I'm assuming Session.Database.OpenView() is available in powerscript, but I
>> can't find a reference to it.. Just calling Session.Database.OpenView(...)
>> Any suggestions ?
>> WiX Toolset Users Mailing List provided by FireGiant
>> WiX Toolset Users Mailing List provided by FireGiant
> WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
More information about the wix-users