psmsi Forum Rss Feed

New Post: Why does Get-MSIProductInfo not return information about the Windows Installer PowerShell Module?

heaths — Wed, 15 Aug 2012 09:37:36 GMT

The module.msi is installed per-user:

> get-msiproductinfo -name *powershell* -context userunmanaged

ProductCode                            ProductVersion      ProductName
-----------                            --------------      -----------
{64C37ACC-A262-4E1F-8564-A12CA8ABC2AD} 2.1.4.0             Windows Installer PowerShell Module

You could also use "All" for the context. The default is "Machine".

New Post: Is it possible to use the Cmdlets on an existing MSI?

heaths — Wed, 15 Aug 2012 09:22:33 GMT

Currently, all the cmdlets do only work for installed or advertised products. I've been debating about how much of an MSI database to expose to cmdlets because editing MSIs directly is dangerous. Developers really should make any changes to source code (like that from http://wixtoolset.org) and rebuild.

The provider was more about extracting files, for which there's other ways.

New Post: Why does Get-MSIProductInfo not return information about the Windows Installer PowerShell Module?

zippy1981 — Mon, 30 Jul 2012 00:30:21 GMT

I can use the Product Code of Visual Studio 2010 to query information with Get-MSIProductInfo:

C:\users\zippy\Downloads> Get-WmiObject Win32_Product -Filter 'Name = "Microsoft Visual Studio 2010 Professional - ENU"'

IdentifyingNumber : {D6B15AE6-B052-363E-B6BB-C4714CBA6509}Name : Microsoft Visual Studio 2010 Professional - ENUVendor : Microsoft CorporationVersion : 10.0.40219Caption : Microsoft Visual Studio 2010 Professional - ENU

C:\users\zippy\Downloads> Get-MSIProductInfo '{D6B15AE6-B052-363E-B6BB-C4714CBA6509}'
ProductCode ProductVersion ProductName----------- -------------- -----------{D6B15AE6-B052-363E-B6BB-C4714CBA6509} 10.0.40219 Microsoft Visual Studio 2010 Professional - ENU

However, this module cannot seem to do the same with itself:

C:\users\zippy\Downloads> Get-WmiObject Win32_Product -Filter 'Name = "Windows Installer PowerShell Module"'

IdentifyingNumber : {4FF51B4D-F17A-4EC6-8301-0BA58AF364F6}Name : Windows Installer PowerShell ModuleVendor : Microsoft CorporationVersion : 2.1.5.0Caption : Windows Installer PowerShell Module

C:\users\zippy\Downloads> Get-MSIProductInfo '{4FF51B4D-F17A-4EC6-8301-0BA58AF364F6}'C:\users\zippy\Downloads> Get-MSIComponentInfo '{4FF51B4D-F17A-4EC6-8301-0BA58AF364F6}'C:\users\zippy\Downloads>

Why is this? I assume this is not actually not a bug in the module, but something I don't understand about MSIs.

New Post: Is it possible to use the Cmdlets on an existing MSI?

zippy1981 — Mon, 30 Jul 2012 00:00:34 GMT

Am I missing something here or do these cmdlets only work on the dtabase of installed MSIs? I've read the code, but there might be something I don't know about MSI.

I'd like to add this feature using the WindowsInstaller.Installer.InvokeMethod used in this PoSH script. If you find that acceptable Heath, I will submit a feature request and a patch.

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

zippy1981 — Sun, 29 Jul 2012 23:55:49 GMT

Ignore the above I just voted for the feature that inspired it.

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

zippy1981 — Sun, 29 Jul 2012 23:53:41 GMT

Heath,

Backup a second. Are you suggesting a PSDrive prrovider for MSIs. Does this exist in any form? If I'm completely off base can you please clarify? Being you can't event specify a MSI path for the cmdlets, I think thats a first step (and I cam to this site to make that feature request).

Justin

New Post: Feature Ideas

tomtrias — Tue, 10 Feb 2009 16:42:46 GMT

I realize that there are already COM types to take advantage of this, but it might be nice to have cmdlets to query an MSI file (database, streams, properties).

New Post: In support of PowerShell v2

heaths — Wed, 28 Jan 2009 16:26:37 GMT

There will be a great number of breaking changes occurring in psmsi as I add support for PowerShell v2 features in addition to the great many new cmdlets that I will providing built on top of the Deployment Tools Foundation (DTF) that is provided along with WiX. Some of these PowerShell v2 features aren't apparent as they ease development and increase robustness of existing features, but some will including transaction support and modules which allow psmsi to be installed per-user and do not require elevation.

But to provide a better description of its functionality, the module and much of the project will be renamed to WindowsInstaller. This CodePlex URL will remain as is, and I may provide a module for backward compability since I will also be renaming the cmdlets to remove a more internal moniker of "MSI" and because the Windows Installer SDK also uses the "wi" moniker for their provided scripts. This module - and perhaps even a snap-in still available to install per-machine - will remain "psmsi". Even the source will undergo significant reorganization to align with these naming changes, but I believe it is necessary going forward as "WindowsInstaller" is much more descriptive than "psmsi".

I considered the ramifications for quite some time and release there's enough downloads of this project to not take this lightly, but PowerShell v1 pales in comparison to v2 which, as projects versions in and out of Microsoft typically go, will serve as a better baseline going forward. But they aren't a side-by-side product, so future changes may require compatibility-breaking changes in my own project. But if possible, going forward I would provide additional assemblies that use new features. But such is not feasible now since even the existing cmdlets can greatly benefit from robustness features added to PowerShell APIs.

I encourage you to try PowerShell v2 CTP3 today. Psmsi does work within CTP3 and likely will for any version of v2 so you can still use what I declared as 1.0 RTW (release to web) and branched for any necessary servicing updates, but there will be no additional features added to that release.

New Post: Feature Ideas

halr9000 — Wed, 08 Oct 2008 12:10:35 GMT

I think this is the sort of thing which could easily be handled with a few functions which could be included with the snapin download perhaps, or (even better IMHO) posted to a script repository such as http://poshcode.org.

New Post: Feature Ideas

heaths — Wed, 08 Oct 2008 09:08:10 GMT

I've considered doing that: taking advantage of the progress capabilities of PowerShell would be cool, but this seems unnecessary given the following would work, for example:

get-msiproductinfo | ?{ $_.Name -match "Foo" } | %{ msiexec.exe /x "$_.ProductCode" /l*vx "$env:temp\$_.Name.log" }

Do you have any particular use cases where this would be easier? It's really a question of priority, though, not whether or not to do it.

New Post: Feature Ideas

jsnielsen — Mon, 22 Sep 2008 09:49:23 GMT

Oh, and an install one too.

MSI-InstallProduct and MSI-RemoveProduct perhaps ?

Of course with the various parameters available :) That would be awesome :)

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.

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?

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.

NEW POST: Feature Ideas

heaths — Tue, 19 Feb 2008 04:33:23 GMT

halr9000 wrote:
Related to the above, I'd like to be able to create an installer package from within powershell. Something simple and straightforward that administrators could use to bundle custom apps. I need to do more research on this. I know there are tools out there now to do it, but last time I looked into it "straightforward" was not a word I would use to describe it. :)

There are too many complexities in a Windows Installer database to use a simple command-line interface to construct it. That would be like using Orca, which requires in-depth knowledge. I recommend using WiX for your package creation needs.

NEW POST: Feature Ideas

halr9000 — Tue, 19 Feb 2008 00:36:01 GMT

Related to the above, I'd like to be able to create an installer package from within powershell. Something simple and straightforward that administrators could use to bundle custom apps. I need to do more research on this. I know there are tools out there now to do it, but last time I looked into it "straightforward" was not a word I would use to describe it. :)

NEW POST: Feature Ideas

halr9000 — Tue, 19 Feb 2008 00:36:00 GMT

NEW POST: Feature Ideas

halr9000 — Tue, 19 Feb 2008 00:35:13 GMT

NEW POST: remote PCs using get-msiproductinfo

heaths — Mon, 11 Feb 2008 08:46:53 GMT

Windows Installer APIs do not support remote calls, however remoting is planned for PowerShell v2.0 (see http://connect.microsoft.com to sign up for pre-releases) and you could use WMI currently to query the Win32_Product class like so,

get-wmiobject -class Win32_Product -computername {remote computer name}

NEW POST: remote PCs using get-msiproductinfo

Toli — Fri, 10 Aug 2007 01:57:38 GMT

Hi,

I'm curious, are you planning on adding the ability to grade the MSI info from remote boxes?

regards,