Windows Installer PowerShell Module 2.2.0 Released

Heath Stewart

Years ago I released PowerShell cmdlets (“command-lets”) that make querying product and patch information easy and robust. Windows PowerShell is a powerful shell that pipes objects – not simply text – and provides full access to the .NET Framework as part of the language (though higher-level constructs are most often better).

Earlier this week I released a new version – version 2.2.0 – of my Windows Installer PowerShell module with great new cmdlets as well as some bug fixes. I’ll be posting more examples online, but have included a few below to give you an idea of what you can do and how they work seamlessly with other PowerShell cmdlets.

What’s Old

You can query what products are installed. Note that with version 2.2.0, the default search context is all accessible contexts (user-unmanaged, user-managed, and machine):

get-msiproductinfo

Like most other PowerShell cmdlets, the output is formatted to show the most important information by default but you can view all properties by piping to select-object:

get-msiproductinfo | select *

These cmdlets follow development guidelines that allow you to pipe them to built-in cmdlets like get-childitem (dir) so you could, for example, get the file size of all cached Windows Installer packages (not the installed size, mind you):

(get-msiproductinfo | dir | measure -sum length).sum / 1mb

You can also get patch information from any or all products, as well as component information. Wondering what product package installed a particular file?

get-msicomponentinfo | where { $_.Path -like "*\devenv.exe" }

You can also store those in a variable for further investigation or pipe them to get-msiproductinfo.

But enough with the old stuff. Let’s move onto the new stuff.

What’s New

PowerShell has powerful extensibility – known as the Extensible Type System (ETS). You can add methods and properties via code, cmdlets, and XML configuration files. Similar to type descriptors, I’ve created a PSPropertyAdapter that creates typed properties for each column in a table or custom query:

get-msitable example.msi -table File

You’ll see all the columns of the file table as properties. This makes it easy to query for, say, all vital files:

get-msitable example.mis -table File | where { $_.Attributes -band 512 }

Cmdlets like get-msisummaryinfo also rely heavily on ETS to adapt the view of common summary information properties to a more customized view based on the file type (product, patch, or transform).

You can also validate product packages that will write rich ICE message objects to the pipeline. What’s more is that you can apply transforms or patches – automatically in sequence order – before ICE validation so you can make sure a patch maintains validity.

dir *.msi | test-msiproduct -patch update1.msp, update2.msp -exclude ICE03

Last but certainly not least, I’ve added cmdlets to install, repair, and uninstall products and patches that integrate with PowerShell in a familiar way by providing progress information and write warnings and errors to the pipeline. This makes it easy to do diagnostics and repairs all from with Windows PowerShell:

dir *.msi | install-msiproduct -chain -target 'C:\Program Files\Example'

Please take a look at more examples on the project web site on CodePlex. I hope you will find these useful and that they may provide value for developing your own cmdlets.

More Information

To suggest improvements or file bugs, please use the bug tracker. Please note that I have decided modifying packages will not be supported since that type of work is best done in your source authoring and compiled by tools like the WiX toolset.

Heath Stewart Principal Software Engineer, Azure SDK

Follow