Windows Installer PowerShell Extensions

New Post: Feature Ideas

jsnielsen — Tue, 02 Sep 2008 09:57:09 GMT

Hey,

I'd love to see an uninstall feature, that takes wither an MSI file or a GUID as an argument, and uninstalls the package.

Updated Wiki: Home

heaths — Fri, 01 Aug 2008 22:42:39 GMT

Project Description

Exposes Windows Installer functionality to PowerShell, providing means to query installed product and patch information and to query views on packages.
PowerShell is a powerful command shell that pipes objects, not just text. Because of this ability, you can string practically unrelated commands together in many different ways to work on different types of objects, all built on .NET.

The Windows Installer extensions in this project expose cmdlets - akin to commands in a batch script - to query Windows Installer products, patches, and package databases.

Features

RFC: I'm requesting comment on how navigation should work in a provider. This would allow mounting an MSI package and browsing the package as an item provider and even copy files out as though it was another file system.

Cmdlets

Get-MSIFileHash get the file hash in a format compatible with installation packages.
Get-MSIFileType determines what type of MSI file - if any - a file is, optionally adding a NoteProperty to an existing FileInfo item.
Get-MSIProductInfo gets information for installed and advertised products.
Get-MSIPatchInfo gets information for patches applied to products, whether superseded or obsolesced.
Get-MSIRelatedProductInfo gets information for related products based on UpgradeCode.
Get-MSISource gets the source list for a product or patch.

Several formats are provided for many of the cmdlets.

Recommend

If there are additional features you'd like to see, please discuss on the thread Feature Ideas, or file a new Feature request if you have some concrete ideas in the Issue Tracker.

Examples

Types sent through the pipeline by these cmdlets are designed to work with standard cmdlets so you can string many cmdlets together. See Examples for a few ideas of what you can do with Windows Installer PowerShell Extensions.

New Post: How should navigation work in an MSI provider?

heaths — Fri, 01 Aug 2008 22:37:46 GMT

How should navigation work in a provider when mounting MSIs? The main conflict is when different components install the same file name to the same target directory. This is allowed when the components' conditions are mutually exclusive, but the idea of the provider is to browse the MSI regardless of conditions. It would be nearly impossible to evaluate these conditions without running a portion of installation up to and including CostFinalize anyway (maybe I should, at least for all known standard and custom action type 51 and 35 CAs). So what I could do is when a name is specified actually output all file objects that match that name. Part of the key would actually be the component ID or GUID. IF a user wanted a single one, a provider-specific parameter to match the ID or GUID would be required. Any comments on that approach?

Created Feature: Migrate to DTF

heaths — Fri, 01 Aug 2008 22:32:09 GMT

To support faster code development, move to DTF (now in WiX). Be sure to define alias properties on objects to match what is available now despite slight variations in the classes like ProductInstallation and PatchInstallation in DTF.

Source code checked in

heaths — Sun, 04 May 2008 15:37:08 GMT

Conditioned the signing task to only execute when the files to sign have changed.

UPDATED RELEASE: 1.0.30411.0 (Apr 11, 2008)

Thu, 17 Apr 2008 09:37:10 GMT

The current list of cmdlets follows.
* Get-MSIFileHash
* Get-MSIFileType
* Get-MSIPatchInfo
* Get-MSIProductInfo
* Get-MSIRelatedProductInfo
* Get-MSISource
The types and formats files are signed with a self-signed certiifcate to allow loading them even under more strict execution policies.

Once installed, when you start PowerShell you must type 'add-pssnapin psmsi' before using the Windows Installer PowerShell Extensions. Optionally, you may add this command to your $profile script to automatically load these extensions whenever you start PowerShell.

*Updated:* updated the branding to use custom bitmaps for the installation package.

Source code checked in

heaths — Thu, 17 Apr 2008 09:30:39 GMT

Added icon and replaced default WiX artwork with custom banner and dialog bitmaps.

Source code checked in

heaths — Wed, 16 Apr 2008 15:49:59 GMT

Changed the warp and set guides for the upcoming icon.

NEW POST: Changing versioning convention

heaths — Sat, 12 Apr 2008 18:45:49 GMT

Because of this and my work on other work-related and personal projects, sticking a schedule hasn't been a primary goal. As such, I'm dropping use of release-driven words like "Alpha", "Beta", "Release Candidate", etc., and am simply posting versions.

In addition, because at one point I toyed with the idea of using a version like 1.0.* in the AssemblyVersionAttribute - which is admittedly lame - and that source was posted, I needed to update my version to 1.0.3MMDD.revision so that the file versions would be newer and Windows Installer would overwrite them correctly.

CREATED RELEASE: 1.0.30411.0 (Apr 11, 2008)

Fri, 11 Apr 2008 21:34:04 GMT

Source code checked in

heaths — Fri, 11 Apr 2008 10:35:19 GMT

Checking in 60 functional and unit tests at 90.90% code coverage.

Source code checked in

heaths — Fri, 04 Apr 2008 09:55:52 GMT

Added additional information for ARP.

Source code checked in

heaths — Thu, 20 Mar 2008 09:24:50 GMT

Solution files needed updating to work in VS.

Source code checked in

heaths — Thu, 20 Mar 2008 09:16:52 GMT

Custom Import was causing problems at load time, and the solution wouldn't build on the command line.

Source code checked in

heaths — Thu, 20 Mar 2008 08:29:12 GMT

Reorganized the directory structure to account for dependent projects.

Source code checked in

heaths — Thu, 20 Mar 2008 08:24:52 GMT

Work in progress; saving to server.

Source code checked in

heaths — Tue, 18 Mar 2008 22:16:12 GMT

Fixed bug that was preventing latest v2 bits from halting after debug prompts.

Source code checked in

heaths — Tue, 18 Mar 2008 19:33:35 GMT

LocalPackage column wasn't long enough.

UPDATED WIKI: Home

heaths — Tue, 18 Mar 2008 18:07:39 GMT

Project Description

Features

Cmdlets

Get-MSIFileHash get the file hash in a format compatible with installation packages.
Get-MSIFileType determines what type of MSI file - if any - a file is, optionally adding a NoteProperty to an existing FileInfo item.
Get-MSIProductInfo gets information for installed and advertised products.
Get-MSIPatchInfo gets information for patches applied to products, whether superseded or obsolesced.
Get-MSIRelatedProductInfo gets information for related products based on UpgradeCode.
Get-MSISource gets the source list for a product or patch.

Several formats are provided for many of the cmdlets.

Recommend

If there are additional features you'd like to see, please discuss on the thread Feature Ideas, or file a new Feature request if you have some concrete ideas in the Issue Tracker.

Examples

CREATED FEATURE: Select records from an MSI or MSP database

heaths — Tue, 18 Mar 2008 18:06:56 GMT

Implement a cmdlet (select-record?) to select records - either by a SQL expression or for a whole table with a scriptblock for a filter - from either an MSI or MSP database. Another way might be to write a single cmdlet for performing queries and updates to a database.