[wix-users] Anyone know how to set a property from a powerscript customaction ?

Sat Apr 30 02:19:37 PDT 2016

Hi Edwin,

Thank you for sharing your notes, experience and recommendations in this
technological area.   I typically write windows installers using c# or c++
and directly calling install APIs. Moving into this tooling only seems like
a step backwards in terms of capability. Myself being obviously new to this
type of tooling, I find it a bit disappointing a robust, underlying runtime
engine has gone unexploited; where developers are fire-walled from
capabilities by front-end languages.

Retrospectively, I see similarity between "old world" macro-assemblers and
domain specific declarative languages. Yet, even in the mid-70s there were
means to share data between isolated processes; first using shared files
and the latest traction focuses on REST over HTTP. Advancing past the 60's
as unix developed, shared memory as "environment variables" became a quick,
low cost means for isolated (protected) processes to interchange data. I
say low cost as temporary files used as "pipes" between processes often
required manually removal by highly technical system and file systems
administrators.

One critical capability required to utilize shared data,and current
requirement today, is the ability to manipulate and transform data; a
capability lacking in most declarative languages. Technologies including
Kleene's 60 year old regexp, seem to be crippling absent from the
landscape. One could argue without robust data manipulation capability,
there's no cause to elaborately share data.

As a normal part of business, technologies deployed require maintenance
over the of the product's life cycle. Each technology requires a new and
different skill, not always available on demand. In larger, structured
organizations geared to servicing over 50 million employees, each
technology deployed is vetted for support-ability and security risk. Policy
implemented as best practice and procedure is a common means to control
long term recurring cost, relieve interoperability issues, and reduce the
number of attack surfaces to mitigate opportunity for malicious activity.

Under mentioned and more thorough conditions, binary files pose a higher
cost to assess vs human readable scripting language. Although some share an
opinion scripting languages not a best practice, in certain environments
they provide an often unseen operational advantage. Contrasted to popular
belief, operational constraints along with technologies' capabilities
determine best practice and selected methods.

As for virus scanners disabling scripting capability...  is the reason for
my interest in powershell. In my deployment environment, policy can be
temporally overridden. It will take some additional procedures with IS
departments to open vbscipt policy and making edits to admin guides (SAM),
however its much shorter time frame than getting a new development project
approved.

There is an open source project that pushes powershell scripts written in
wix to the PS motor. https://github.com/flcdrg/PowerShellWixExtension  It
doesn't look like it's been touched much in the past year and looks like a
great starting point.  There is likely a COM technique to share object
between the PS motor and installer instantiations.  Being a long time OS
kernel developer, first instinct makes me look towards software interrupts
to an procedure call pointing to the installer's object functions. I'm sure
there is a better way or at lest there's a COM/.NET api to do the heavy
lifting.

If I just had the time...

cheers,
g

On Fri, Apr 29, 2016 at 10:59 PM, Edwin Castro <egcastr at gmail.com> wrote:

> 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:
>
>
> http://0ptikghost.blogspot.com/2011/03/executing-powershell-scripts-silently.html
>
> 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:
>
>> Phill,
>>
>> 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
>> Jscript.
>>
>> 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.
>>
>> I
>>
>>
>> On Fri, Apr 29, 2016 at 7:11 AM, Phill Hogland <phill.hogland at rimage.com>
>> wrote:
>>
>> 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:
>>>
>>>
>>> http://stackoverflow.com/questions/1373600/how-do-i-populate-a-combobox-at-install-time-in-wix
>>>
>>> I'm assuming Session.Database.OpenView() is available in powerscript,
>>> but I
>>> can't find a reference to it..  Just calling
>>> Session.Database.OpenView(...)
>>>   fails.
>>>
>>> Any suggestions ?
>>>
>>> -g
>>>
>>> ____________________________________________________________________
>>> WiX Toolset Users Mailing List provided by FireGiant
>>> http://www.firegiant.com/
>>>
>>> ____________________________________________________________________
>>> WiX Toolset Users Mailing List provided by FireGiant
>>> http://www.firegiant.com/
>>>
>>> ____________________________________________________________________
>> WiX Toolset Users Mailing List provided by FireGiant
>> http://www.firegiant.com/
>>
>>
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>