Vista - Windows Installer automation interface problems in PowerShell?

I'm having trouble using the Windows Installer COM automation interfaces
from within PowerShell. The object has a ProgId of
WindowsInstaller.Installer, and is exposed by msi.dll in the System32 folder
(version 3.1.4000.2435 on my XPSP2 system).

A short VBScript sample works fine in getting object data:
Set msi = CreateObject("WindowsInstaller.Installer")
WScript.Echo "Version:", msi.Version
For each product in msi.Products
WScript.Echo product
next
This returns the version number and the StringList of GUIDs for products.

In PowerShell, however, I get back a generic COM object (methods not shown
because they are only the generic ones for System.__ComObject):

PS> $wii = New-Object -ComObject WindowsInstaller.Installer
PS> $wii | gm


TypeName: System.__ComObject

This object has no properties, of course. Checking through the object with a
type library browser, I noticed that it has 12 dispinterfaces, but no
coclasses - I don't know if this ties in to the reason it doesn't work from
PS.

Why does this fail? There definitely are other ways to get to some of the
installer functionality, but I'm more interested in the specific reasons
that the installer reference comes back as a generic COM object in PS, and -
if there is a way around it - determining how one can get access to the COM
interfaces from PS in spite of this.

Hi Alex,
See my blog posting on this issue at:
http://abhishek225.spaces.live.com/blog/cns!13469C7B7CE6E911!165.entry

In order to "adapt" the COM object we attempt to get to the TypeInfo for the
object. If we cannot get to the TypeInfo we are unable to adapt the object.
We are aware of the issue and are investigating ways to improve this. In the
meantime there are couple of workarounds as discussed in the blog.

--
Abhishek Agrawal [MSFT]
http://abhishek225.spaces.live.com
Windows PowerShell Team
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.


"Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
news:ObE1laztGHA.3964@TK2MSFTNGP04.phx.gbl...
> I'm having trouble using the Windows Installer COM automation interfaces
> from within PowerShell. The object has a ProgId of
> WindowsInstaller.Installer, and is exposed by msi.dll in the System32
> folder (version 3.1.4000.2435 on my XPSP2 system).
>
> A short VBScript sample works fine in getting object data:
> Set msi = CreateObject("WindowsInstaller.Installer")
> WScript.Echo "Version:", msi.Version
> For each product in msi.Products
> WScript.Echo product
> next
> This returns the version number and the StringList of GUIDs for products.
>
> In PowerShell, however, I get back a generic COM object (methods not shown
> because they are only the generic ones for System.__ComObject):
>
> PS> $wii = New-Object -ComObject WindowsInstaller.Installer
> PS> $wii | gm
>
>
> TypeName: System.__ComObject
>
> This object has no properties, of course. Checking through the object with
> a type library browser, I noticed that it has 12 dispinterfaces, but no
> coclasses - I don't know if this ties in to the reason it doesn't work
> from PS.
>
> Why does this fail? There definitely are other ways to get to some of the
> installer functionality, but I'm more interested in the specific reasons
> that the installer reference comes back as a generic COM object in PS,
> and - if there is a way around it - determining how one can get access to
> the COM interfaces from PS in spite of this.
>
>

That's an excellent blog entry. It explains precisely the issues of concern,
and both workarounds are practical.


"Abhishek Agrawal [MSFT]" <abhiag@online.microsoft.com> wrote in message
news:Oed8$D0tGHA.4872@TK2MSFTNGP02.phx.gbl...
> Hi Alex,
> See my blog posting on this issue at:
> http://abhishek225.spaces.live.com/blog/cns!13469C7B7CE6E911!165.entry
>
> In order to "adapt" the COM object we attempt to get to the TypeInfo for
> the object. If we cannot get to the TypeInfo we are unable to adapt the
> object. We are aware of the issue and are investigating ways to improve
> this. In the meantime there are couple of workarounds as discussed in the
> blog.
>
> --
> Abhishek Agrawal [MSFT]
> http://abhishek225.spaces.live.com
> Windows PowerShell Team
> Microsoft Corporation
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> "Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
> news:ObE1laztGHA.3964@TK2MSFTNGP04.phx.gbl...
>> I'm having trouble using the Windows Installer COM automation interfaces
>> from within PowerShell. The object has a ProgId of
>> WindowsInstaller.Installer, and is exposed by msi.dll in the System32
>> folder (version 3.1.4000.2435 on my XPSP2 system).
>>
>> A short VBScript sample works fine in getting object data:
>> Set msi = CreateObject("WindowsInstaller.Installer")
>> WScript.Echo "Version:", msi.Version
>> For each product in msi.Products
>> WScript.Echo product
>> next
>> This returns the version number and the StringList of GUIDs for products.
>>
>> In PowerShell, however, I get back a generic COM object (methods not
>> shown because they are only the generic ones for System.__ComObject):
>>
>> PS> $wii = New-Object -ComObject WindowsInstaller.Installer
>> PS> $wii | gm
>>
>>
>> TypeName: System.__ComObject
>>
>> This object has no properties, of course. Checking through the object
>> with a type library browser, I noticed that it has 12 dispinterfaces, but
>> no coclasses - I don't know if this ties in to the reason it doesn't work
>> from PS.
>>
>> Why does this fail? There definitely are other ways to get to some of the
>> installer functionality, but I'm more interested in the specific reasons
>> that the installer reference comes back as a generic COM object in PS,
>> and - if there is a way around it - determining how one can get access to
>> the COM interfaces from PS in spite of this.
>>
>>
>
>

By the way, did you actually test the tlbimp use? It looks like you simply
noted it as a general workaround. In the case of msi.dll, if I generate a
signed assembly (msiwrapper.dll) and GAC it, I can successfully load the
assembly - but it isn't possible to create an instance (presumably since
Installer is an interface and not a class).

I can use [msiwrapper.Installer].PSBase to get access to the object and then
see the methods on it, but then it's necessary to use
[msiwrapper.Installer].InvokeMember with all of the arguments specified.
Overall, it still looks like your type extension approach is much superior.


"Abhishek Agrawal [MSFT]" <abhiag@online.microsoft.com> wrote in message
news:Oed8$D0tGHA.4872@TK2MSFTNGP02.phx.gbl...
> Hi Alex,
> See my blog posting on this issue at:
> http://abhishek225.spaces.live.com/blog/cns!13469C7B7CE6E911!165.entry
>
> In order to "adapt" the COM object we attempt to get to the TypeInfo for
> the object. If we cannot get to the TypeInfo we are unable to adapt the
> object. We are aware of the issue and are investigating ways to improve
> this. In the meantime there are couple of workarounds as discussed in the
> blog.
>
> --
> Abhishek Agrawal [MSFT]
> http://abhishek225.spaces.live.com
> Windows PowerShell Team
> Microsoft Corporation
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> "Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
> news:ObE1laztGHA.3964@TK2MSFTNGP04.phx.gbl...
>> I'm having trouble using the Windows Installer COM automation interfaces
>> from within PowerShell. The object has a ProgId of
>> WindowsInstaller.Installer, and is exposed by msi.dll in the System32
>> folder (version 3.1.4000.2435 on my XPSP2 system).
>>
>> A short VBScript sample works fine in getting object data:
>> Set msi = CreateObject("WindowsInstaller.Installer")
>> WScript.Echo "Version:", msi.Version
>> For each product in msi.Products
>> WScript.Echo product
>> next
>> This returns the version number and the StringList of GUIDs for products.
>>
>> In PowerShell, however, I get back a generic COM object (methods not
>> shown because they are only the generic ones for System.__ComObject):
>>
>> PS> $wii = New-Object -ComObject WindowsInstaller.Installer
>> PS> $wii | gm
>>
>>
>> TypeName: System.__ComObject
>>
>> This object has no properties, of course. Checking through the object
>> with a type library browser, I noticed that it has 12 dispinterfaces, but
>> no coclasses - I don't know if this ties in to the reason it doesn't work
>> from PS.
>>
>> Why does this fail? There definitely are other ways to get to some of the
>> installer functionality, but I'm more interested in the specific reasons
>> that the installer reference comes back as a generic COM object in PS,
>> and - if there is a way around it - determining how one can get access to
>> the COM interfaces from PS in spite of this.
>>
>>
>
>

Yes, I had tried the tlbimp.exe and faced the same issues you described. In
the blog I described tlbimp.exe as a general workaround for dealing with COM
types. For WindowsInstaller, my guess is one would need to generate a custom
interop library. I have not looked into that yet though.
--
Abhishek Agrawal [MSFT]
Windows PowerShell Team
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

"Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
news:ukjFjN1tGHA.4456@TK2MSFTNGP06.phx.gbl...
> By the way, did you actually test the tlbimp use? It looks like you simply
> noted it as a general workaround. In the case of msi.dll, if I generate a
> signed assembly (msiwrapper.dll) and GAC it, I can successfully load the
> assembly - but it isn't possible to create an instance (presumably since
> Installer is an interface and not a class).
>
> I can use [msiwrapper.Installer].PSBase to get access to the object and
> then see the methods on it, but then it's necessary to use
> [msiwrapper.Installer].InvokeMember with all of the arguments specified.
> Overall, it still looks like your type extension approach is much
> superior.
>
>
> "Abhishek Agrawal [MSFT]" <abhiag@online.microsoft.com> wrote in message
> news:Oed8$D0tGHA.4872@TK2MSFTNGP02.phx.gbl...
>> Hi Alex,
>> See my blog posting on this issue at:
>> http://abhishek225.spaces.live.com/blog/cns!13469C7B7CE6E911!165.entry
>>
>> In order to "adapt" the COM object we attempt to get to the TypeInfo for
>> the object. If we cannot get to the TypeInfo we are unable to adapt the
>> object. We are aware of the issue and are investigating ways to improve
>> this. In the meantime there are couple of workarounds as discussed in the
>> blog.
>>
>> --
>> Abhishek Agrawal [MSFT]
>> http://abhishek225.spaces.live.com
>> Windows PowerShell Team
>> Microsoft Corporation
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
>> news:ObE1laztGHA.3964@TK2MSFTNGP04.phx.gbl...
>>> I'm having trouble using the Windows Installer COM automation interfaces
>>> from within PowerShell. The object has a ProgId of
>>> WindowsInstaller.Installer, and is exposed by msi.dll in the System32
>>> folder (version 3.1.4000.2435 on my XPSP2 system).
>>>
>>> A short VBScript sample works fine in getting object data:
>>> Set msi = CreateObject("WindowsInstaller.Installer")
>>> WScript.Echo "Version:", msi.Version
>>> For each product in msi.Products
>>> WScript.Echo product
>>> next
>>> This returns the version number and the StringList of GUIDs for
>>> products.
>>>
>>> In PowerShell, however, I get back a generic COM object (methods not
>>> shown because they are only the generic ones for System.__ComObject):
>>>
>>> PS> $wii = New-Object -ComObject WindowsInstaller.Installer
>>> PS> $wii | gm
>>>
>>>
>>> TypeName: System.__ComObject
>>>
>>> This object has no properties, of course. Checking through the object
>>> with a type library browser, I noticed that it has 12 dispinterfaces,
>>> but no coclasses - I don't know if this ties in to the reason it doesn't
>>> work from PS.
>>>
>>> Why does this fail? There definitely are other ways to get to some of
>>> the installer functionality, but I'm more interested in the specific
>>> reasons that the installer reference comes back as a generic COM object
>>> in PS, and - if there is a way around it - determining how one can get
>>> access to the COM interfaces from PS in spite of this.
>>>
>>>
>>
>>
>
>

btw, I did come across this thread on issues with using WindowsInstaller
from C#/.Net

http://dotnet247.com/247reference/msgs/12/61188.aspx

--
Abhishek Agrawal [MSFT]
Windows PowerShell Team
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

"Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
news:ukjFjN1tGHA.4456@TK2MSFTNGP06.phx.gbl...
> By the way, did you actually test the tlbimp use? It looks like you simply
> noted it as a general workaround. In the case of msi.dll, if I generate a
> signed assembly (msiwrapper.dll) and GAC it, I can successfully load the
> assembly - but it isn't possible to create an instance (presumably since
> Installer is an interface and not a class).
>
> I can use [msiwrapper.Installer].PSBase to get access to the object and
> then see the methods on it, but then it's necessary to use
> [msiwrapper.Installer].InvokeMember with all of the arguments specified.
> Overall, it still looks like your type extension approach is much
> superior.
>
>
> "Abhishek Agrawal [MSFT]" <abhiag@online.microsoft.com> wrote in message
> news:Oed8$D0tGHA.4872@TK2MSFTNGP02.phx.gbl...
>> Hi Alex,
>> See my blog posting on this issue at:
>> http://abhishek225.spaces.live.com/blog/cns!13469C7B7CE6E911!165.entry
>>
>> In order to "adapt" the COM object we attempt to get to the TypeInfo for
>> the object. If we cannot get to the TypeInfo we are unable to adapt the
>> object. We are aware of the issue and are investigating ways to improve
>> this. In the meantime there are couple of workarounds as discussed in the
>> blog.
>>
>> --
>> Abhishek Agrawal [MSFT]
>> http://abhishek225.spaces.live.com
>> Windows PowerShell Team
>> Microsoft Corporation
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>>
>> "Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
>> news:ObE1laztGHA.3964@TK2MSFTNGP04.phx.gbl...
>>> I'm having trouble using the Windows Installer COM automation interfaces
>>> from within PowerShell. The object has a ProgId of
>>> WindowsInstaller.Installer, and is exposed by msi.dll in the System32
>>> folder (version 3.1.4000.2435 on my XPSP2 system).
>>>
>>> A short VBScript sample works fine in getting object data:
>>> Set msi = CreateObject("WindowsInstaller.Installer")
>>> WScript.Echo "Version:", msi.Version
>>> For each product in msi.Products
>>> WScript.Echo product
>>> next
>>> This returns the version number and the StringList of GUIDs for
>>> products.
>>>
>>> In PowerShell, however, I get back a generic COM object (methods not
>>> shown because they are only the generic ones for System.__ComObject):
>>>
>>> PS> $wii = New-Object -ComObject WindowsInstaller.Installer
>>> PS> $wii | gm
>>>
>>>
>>> TypeName: System.__ComObject
>>>
>>> This object has no properties, of course. Checking through the object
>>> with a type library browser, I noticed that it has 12 dispinterfaces,
>>> but no coclasses - I don't know if this ties in to the reason it doesn't
>>> work from PS.
>>>
>>> Why does this fail? There definitely are other ways to get to some of
>>> the installer functionality, but I'm more interested in the specific
>>> reasons that the installer reference comes back as a generic COM object
>>> in PS, and - if there is a way around it - determining how one can get
>>> access to the COM interfaces from PS in spite of this.
>>>
>>>
>>
>>
>
>

This further confirms that it is an intrinsic COM/.NET problem.

Issues like this are one of the reasons why I've suggested in the past that
it would be a good idea to provide a mechanism for PS directly hosting
Active Scripting languages by using the Script Control. Even though this
would require working across a COM/.NET interface, it would allow us to
easily "wrap" access to ugly COM classes.

"Abhishek Agrawal [MSFT]" <abhiag@online.microsoft.com> wrote in message
news:u25d7c2tGHA.3392@TK2MSFTNGP04.phx.gbl...
> btw, I did come across this thread on issues with using WindowsInstaller
> from C#/.Net
>
> http://dotnet247.com/247reference/msgs/12/61188.aspx
>
> --
> Abhishek Agrawal [MSFT]
> Windows PowerShell Team
> Microsoft Corporation
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> "Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
> news:ukjFjN1tGHA.4456@TK2MSFTNGP06.phx.gbl...
>> By the way, did you actually test the tlbimp use? It looks like you
>> simply noted it as a general workaround. In the case of msi.dll, if I
>> generate a signed assembly (msiwrapper.dll) and GAC it, I can
>> successfully load the assembly - but it isn't possible to create an
>> instance (presumably since Installer is an interface and not a class).
>>
>> I can use [msiwrapper.Installer].PSBase to get access to the object and
>> then see the methods on it, but then it's necessary to use
>> [msiwrapper.Installer].InvokeMember with all of the arguments specified.
>> Overall, it still looks like your type extension approach is much
>> superior.
>>
>>
>> "Abhishek Agrawal [MSFT]" <abhiag@online.microsoft.com> wrote in message
>> news:Oed8$D0tGHA.4872@TK2MSFTNGP02.phx.gbl...
>>> Hi Alex,
>>> See my blog posting on this issue at:
>>> http://abhishek225.spaces.live.com/blog/cns!13469C7B7CE6E911!165.entry
>>>
>>> In order to "adapt" the COM object we attempt to get to the TypeInfo for
>>> the object. If we cannot get to the TypeInfo we are unable to adapt the
>>> object. We are aware of the issue and are investigating ways to improve
>>> this. In the meantime there are couple of workarounds as discussed in
>>> the blog.
>>>
>>> --
>>> Abhishek Agrawal [MSFT]
>>> http://abhishek225.spaces.live.com
>>> Windows PowerShell Team
>>> Microsoft Corporation
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights.
>>>
>>>
>>> "Alex K. Angelopoulos [MVP]" <aka@online.mvps.org> wrote in message
>>> news:ObE1laztGHA.3964@TK2MSFTNGP04.phx.gbl...
>>>> I'm having trouble using the Windows Installer COM automation
>>>> interfaces from within PowerShell. The object has a ProgId of
>>>> WindowsInstaller.Installer, and is exposed by msi.dll in the System32
>>>> folder (version 3.1.4000.2435 on my XPSP2 system).
>>>>
>>>> A short VBScript sample works fine in getting object data:
>>>> Set msi = CreateObject("WindowsInstaller.Installer")
>>>> WScript.Echo "Version:", msi.Version
>>>> For each product in msi.Products
>>>> WScript.Echo product
>>>> next
>>>> This returns the version number and the StringList of GUIDs for
>>>> products.
>>>>
>>>> In PowerShell, however, I get back a generic COM object (methods not
>>>> shown because they are only the generic ones for System.__ComObject):
>>>>
>>>> PS> $wii = New-Object -ComObject WindowsInstaller.Installer
>>>> PS> $wii | gm
>>>>
>>>>
>>>> TypeName: System.__ComObject
>>>>
>>>> This object has no properties, of course. Checking through the object
>>>> with a type library browser, I noticed that it has 12 dispinterfaces,
>>>> but no coclasses - I don't know if this ties in to the reason it
>>>> doesn't work from PS.
>>>>
>>>> Why does this fail? There definitely are other ways to get to some of
>>>> the installer functionality, but I'm more interested in the specific
>>>> reasons that the installer reference comes back as a generic COM object
>>>> in PS, and - if there is a way around it - determining how one can get
>>>> access to the COM interfaces from PS in spite of this.
>>>>
>>>>
>>>
>>>
>>
>>
>
>