psmsi Work Item Rss Feed

Edited Feature: Cmdlets for querying summary information stream [2756]

heaths — Mon, 20 May 2013 16:41:15 GMT

Create cmdlets to query the summary information stream for any storage passed to it, along with substorages (optionally?). For Windows Installer file types, create handlers to display proper property names (perhaps along with standard names) to give more meaning (since PROPIDs are overloaded like Revision Number, Template, etc.).

Edited Feature: Add cmdlet for validation [9423]

heaths — Mon, 20 May 2013 16:41:15 GMT

Add a cmdlet for validating MSIs - maybe even MSPs or MSTs applied to MSIs. The output is an object with properties for the ICE messages. But to easily select records based on messages consider how the table/column/primary keys would be output. Could be some sort of reference to a record that would work with the record selection / update cmdlets.
There should be a parameter to grab the default "darice.cub" from Orca by using a component search. With -Include and -Exclude, first generate inclusions (default is all) then remove exclusions (if any).
According to docs, "validate" is not valid but should actually be "test" as shown below.
Usage:
test-wipackage [-Path] <String[]> [[-CubPath] <String[]>] [-Default] [-Include <String[]>] [-Exclude <String[]>]

Edited Feature: Given a list of products and patches, return would-be sequence of patches [9121]

heaths — Mon, 20 May 2013 16:41:15 GMT

Create a cmdlet that would accept a list of patch packages and/or MSP XML file, and an optional list of product packages or ProductCodes. If no products were provided, then the union of the target ProductCodes should be used. Machine state can be optionally ignored.
Possible definitions:
get-wipatchsequence [-Path] <string[]> [[-ProductPath] <string[]>
get-wipatchsequence [-LiteralPath] <string[]> [[-ProductPath] <string[]>
get-wipatchsequence [-Path] <string[]> [[-ProductCode] <string[]> [-UserContext <UserContexts] [-UserSid <string>]
get-wipatchsequence [-LiteralPath] <string[]> [[-ProductCode] <string[]> [-UserContext <UserContexts] [-UserSid <string>]
The object returned has Sequence, Path (attach PSPath), and ProductCode or product package path (depending on parameterset). The default view would group by product and order by Sequence.

Commented Feature: Provider for mounting MSI files [5778]

heaths — Mon, 20 May 2013 16:39:44 GMT

Create a provider for mounting MSI files as PSDrives so that users can navigate and copy out of the media.
Comments: Given the new read-only stance I'm taking with the module (install package changes should be done in-source using your toolset - like WiX - to make sure everything is valid), this would be overkill. I will consider a cmdlet to extract files or even run an admin installation for a future release. Something like Export-MSIPackageFile.

Edited Feature: Provider for mounting MSI files [5778]

heaths — Mon, 20 May 2013 16:39:44 GMT

Create a provider for mounting MSI files as PSDrives so that users can navigate and copy out of the media.

Edited Feature: Given a list of products and patches, return would-be sequence of patches [9121]

heaths — Mon, 20 May 2013 16:37:20 GMT

Edited Issue: Files are not being signed [9173]

heaths — Mon, 20 May 2013 16:37:02 GMT

The *.ps1 and *.psm1 files are not being signed, even before the code was removed from the *.csproj files. The previous method of using PowerShell didn't always work, but the SignFile task only handles PE files, and XML-based Office files like .docx files. It does not sign all Authenticode-signable files.
The files could be signed prior to check-in after every edit, but this is not easily sustainable. A task could be created either to host PowerShell directly or to properly use the Crypto APIs to Authenticode sign the files.

Created Issue: Installer handles are not being closed [14454]

heaths — Mon, 20 May 2013 16:33:58 GMT

By using a PSPropertyAdapter, installer handles must be kept open so database, view, and record information can be retrieved when needed (which may not be right away). Will probably have to dump the PSPropertyAdapter and just do everything in the cmdlets. The problem is that, unless I use PSNoteProperty (which has no explicit type - just returns Value.GetType()), there's really no supported way to create a concrete-looking object since I can't supportedly extend PSProperty(Info) and no other PSPropertyInfo derivative supports the scenario.

Looking through Reflector - at least for PSv2 and PSv3 - extending PSPropertyInfo may work.

The question will be whether to keep the PSPropertyAdapter in addition to provide a near-consistent view of records no matter how retrieved.

(PS: Same goes for the SummaryInfo, since an open handle is required to get values.)

Closed Feature: Select records from an MSI or MSP database [5779]

heaths — Sun, 19 May 2013 19:29:28 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.
Comments: Coming in the 2.2 release soon.

Created Issue: No PSPath for component key path starting with "20:\CLSID" [14453]

heaths — Sat, 18 May 2013 11:34:56 GMT

There another registry key root no currently handled by the module that uses "20:", like in "20:\CLSID". This is probably another root ID for HKCR but need to test this out.

Closed Issue: Cmdlets with PassThru parameters do not chain correctly [5554]

heaths — Tue, 30 Apr 2013 01:02:50 GMT

For those cmdlets that provide a -PassThru switch, they cannot be chained such that the NoteProperty objects they add are all visible.
Repro:
dir | get-msifilehash -passthru | get-msifiletype -passthru | ft name,msi*
Expected:
Name, MSIFileType, MSIHashPart1, MSIHashPart2, MSIHashPart3, and MSIHashPart4 are all displayed.
Result:
Name and MSIFileType are only displayed.

Closed Issue: Typo in Error_InvalidContext [14452]

heaths — Tue, 30 Apr 2013 01:02:31 GMT

The message for Error_InvalidContext reads, "The user context "None" is not validation for this operation." The word "validation" should be "valid".

Created Issue: Typo in Error_InvalidContext [14452]

heaths — Thu, 25 Apr 2013 21:34:07 GMT

The message for Error_InvalidContext reads, "The user context "None" is not validation for this operation." The word "validation" should be "valid".

Commented Issue: Cmdlets with PassThru parameters do not chain correctly [5554]

heaths — Fri, 29 Mar 2013 18:25:54 GMT

Edited Issue: Cmdlets with PassThru parameters do not chain correctly [5554]

heaths — Fri, 29 Mar 2013 18:25:54 GMT

Commented Issue: Cmdlets with PassThru parameters do not chain correctly [5554]

heaths — Thu, 16 Jun 2011 00:59:07 GMT

Another idea would just be to append ScriptMethods to the typedata, such that only when you retrieve these properties the cmdlets would run. The only problem is that remove-module wouldn't remove that type data update, but the ScriptMethod could first validate if the cmdlet is even available. Would have to see how that would work with import-module -prefix.

Closed Issue: Could not load ... Failed to grant minimum permission requests. [14451]

heaths — Sat, 04 Dec 2010 18:59:02 GMT

After installing the Module.msi and trying to import the module I'm getting the error:

PS C:\Users\Administrator> import-module msi
Import-Module : Could not load file or assembly 'Microsoft.Deployment.WindowsInstaller, Version=3.0.0.0, Culture=neutra
l, PublicKeyToken=ce35f76fcda82bad' or one of its dependencies. Failed to grant minimum permission requests. (Exception
from HRESULT: 0x80131417)
At line:1 char:14
+ import-module <<<< msi
+ CategoryInfo : InvalidOperation: (:) [Import-Module], FileLoadException
+ FullyQualifiedErrorId : FormatXmlUpateException,Microsoft.PowerShell.Commands.ImportModuleCommand

looks like there are problems since the module was installed on a network share. my home dir is redirected to a network share.
Why is the module installed in my home dir instead of in C:\Windows\System32\WindowsPowershell\v1.0\Modules
Comments:

The CLR (the runtime for .NET) knows when it's run from the network and fewer permissions (including those to call native APIs, which the assembly does) are granted.

The module is not installed to %WINDIR%\System32 by design - only privileges products can write there, and this is actually a Windows Logo violation. Modules are most often per-user instead of per-machine, so I can only write to a per-user location - which is designed by the PowerShell team to be in your Documents folder (not sure why since %APPDATA% would make more sense). But you could install SnapIn.msi instead. To load that you'll need to use "add-pssnapin psmsi".

Reopened Issue: Cmdlets with PassThru parameters do not chain correctly [5554]

heaths — Sat, 04 Dec 2010 18:52:49 GMT

Created Issue: Could not load ... Failed to grant minimum permission requests. [14451]

BZanten — Tue, 12 Oct 2010 18:29:41 GMT

Closed Issue: Cmdlets querying the same information cannot be chained [9464]

heaths — Tue, 20 Jul 2010 02:16:29 GMT

Cmdlets that query similar information - like get-wiproductinfo or get-wicomponentinfo - cannot be chained together whether one after another or separated by other cmdlets as shown below:
PS> get-wiproductinfo | get-wiproductinfo
PS> get-wiproductinfo | get-wicomponentinfo "{...}" | get-wiproductinfo
PS> get-wiproductinfo "{...}" | get-wicomponentinfo "{...}" | get-wiproductinfo
The reason is that the registry keys that are being enumerated are opened by one cmdlet invocation and cannot be reopened by the same cmdlet later running in the same thread. One possible solution is to process all input in EndProcessing for each cmdlet so that by then the registry key being enumerated is closed.
Comments: Resolved with changeset 56747.