Hello,

I am trying to use the windows installer COM object with powershell
and I'm running into problems. It looks like the shell holds on to
the .wsi file that I'm trying to change with an UPDATE call, so I can
run the ps1 script exactly once and after that I cannot access the
file (either through the shell or a tool like ORCA) until I close the
shell.

I confirmed this fact using the windows process explorer. After
executing the ps1 script I can find the .wsi file under "find handle"
and it is held by the shell from which the script was executed.

So, I created a VB script that essentially does the exact same operation on
the .wsi file and it turns out that I can run this any number of times
from the same shell without any problems.

What am I missing????
I have included the VB and PS1 script here. Any help is appreciated.

=======================VB SCRIPT
Dim installer : Set installer = Nothing
Set installer = Wscript.CreateObject("WindowsInstaller.Installer")
Dim databasePath:databasePath = Wscript.Arguments(0)
Dim database : Set database = installer.OpenDatabase(databasePath, 1)
Dim query, view
query = Wscript.Arguments(1)
Set view = database.OpenView(query)
view.Execute
database.Commit

=======================PS1 SCRIPT
$file = $args[0]
$installer = new-object -comobject "WindowsInstaller.Installer"
$database = $installer.InvokeMethod( "OpenDatabase", $file, 1 )
$view = $database.InvokeMethod( "OpenView", "UPDATE  Property SET
Property.Value='32.0' WHERE Property.Property='ProductVersion' ")
$view.InvokeMethod( "Execute" )
$view.InvokeMethod( "Close" )
$database.InvokeMethod( "Commit" )

[System.Runtime.Interopservices.Marshal]::ReleaseComObject($installer)
$installer = $null

=========================Types.ps1xml, has to be called using update-
typedate Types.ps1xml before running the ps1 script

 
  System.__ComObject
   
        [script removed]  InvokeMethod
 [script removed]         $type = $this.gettype();
        #write-host $type
        $index = $args.count -1 ;
        #write-host "Index :" $index
        $methodargs=$args[1..$index]
        #write-host $methodargs
        #write-host "Arg 0 :" $args[0]
        $type.invokeMember($args[0],
[System.Reflection.BindingFlags]::InvokeMethod,$null,$this,
$methodargs)
        [script removed]
 
     
   

I ran into that last week only using add-member and VS.  My work around/fix was to call powershell.exe from within my powershell console.  Test my cmdlet then exit back out so VS could access the file for the next build.   It does appear that powershell.exe maintains a lock on the file.

My guess as to why vbscript isn't doing the same thing is that cscript.exe terminates once the vbscript is done.  They behave the same it's just that there is no persistent console(process) with vbscript.

powershell.exe -nologo -noexit -file \script.ps1

I know that's not much help, but it's not just you, and it is very annoying...
~Glenn

Hi Glenn,

Thanks for your response. What you said about why VBscript behaves differently from PS definitely makes sense. So when you call powershell.exe from within your PS script you are essentially doing the same thing as calling cscript from the PS script (correct me if I'm wrong here).

So, another question:

Does the PS shell lock the file only when I open the file in read/write mode? If it is read-only, I have no problems running my script repeatedly.

Thanks again.

You're right on the money.  When you launch powershell.exe from within powershell it starts a new instance in your current console.  when your done type exit and it will kill that session/process and return you to your original thread. 

Or in your case from within a ps1 script simply omit the -noexit switch and it will terminate just like cscript.

I've also observed the same behavior with read vs readwrite.  It's still makes no senses though... Why have a remove-module cmdlet if the process doesn't let go of the file.  It appears that the use case for that cmdlet is to "hide" cmds not unload them...

Ahhh well, glad to help
~Glenn

the $database object returned probably needs to be disposed as well as $installer. Call ReleaseComObject against that too. As the others have remarked, the vbscript engine quits after you run a script and does the clean up for you.

- Oisin

I got this response from JMinnick on the Microsoft discussion groups. It was really helpful in resolving this. Hope it will help others too. It turns out that the $view has to be released too. This is really not intuitive (Ithink so atleast), because no "new-objects" are created for database and view, but they have to be released!!! I have no experience with managed code, but this I thought was really weird.

I quote JMinnick's response:

"Linus,

Did you try releasing the $view and $database objects as well? Excel will do
something similar when you create an instance in powershell. Any
object/variable that used my Excel object has to be released otherwise Excel
still shows up in Task Manager. "


Here is the link to the discussion group:
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.windows.powershell&tid=9add7a9b-b4ce-462d-bec7-bf0abaf5c17c&cat=en_US_d02fc761-3f6b-402c-82f6-ba1a8875c1a7&lang=en&cr=&sloc=en-us&m=1&p=1