Any tips on how to do this? I did not create the MSI, and it wont uninstal unless a process is killed first.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
You need to add a Custom Action, conditioned to run only during an uninstall (REMOVE~="ALL"). You'll find your best option is a VBScript-driven CA, as there are a quadzillion examples of scripts around which kill processes. Make sure, however, that any script you use is properly error-trapped.
Answered 11/23/2009 by: VBScab
Red Belt

Please log in to comment
0
You could also write a simple AutoIT script to detect and kill the process before it runs the installer.
Answered 11/23/2009 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
Cheers thanks. I know if I want a custom action at install time where I did not create the msi, I call it with a transform, I can't call a transform at uninstall?
Answered 11/23/2009 by: blade2
Blue Belt

Please log in to comment
0
If you have a vendor MSI then you should create a transform and add the custom action to Kill Process in the transform. As VBScab mentioned it should be set with condition REMOVE~="ALL" which will run during uninstall.

I usually sequence if before AppSearch with a Execution Property set to Synchronous and Execution Option set to Immediate.
Answered 11/23/2009 by: PackageExpert
Blue Belt

Please log in to comment
0
Hi,
Before uninstallation check the application is running
TASKLIST | FINDSTR /I "application.exe"
if the application is running , kill the application and uninstall.. I hope it will help you
Answered 11/23/2009 by: shakeela511
Yellow Belt

Please log in to comment
0
ok cheers, now I get it. sorry a bit fuzzy on VBSCAB's reply.

Thanks
Answered 11/24/2009 by: blade2
Blue Belt

Please log in to comment
0
TASKLIST | FINDSTR /I "application.exe" Too messy. Most of the process-killing scripts around use the WMI object to enumerate the process list and, when the target process is found, get its process ID, using that to terminate the process. Avoid those scripts which kill named processes: always use the process ID. You can hopefully work out why.
Answered 11/24/2009 by: VBScab
Red Belt

Please log in to comment
0
Hi VBScab,
If we kill the process , by process name, there is danger of termination of other processes related to the application also.
If we kill the process by using process id, which unique for the application, we can avoid above problem.
Thatswhy we cant use processnames to kill the application . Is it?[:o]
Answered 11/24/2009 by: shakeela511
Yellow Belt

Please log in to comment
0
Exactly so.
Answered 11/25/2009 by: VBScab
Red Belt

Please log in to comment
0
Thanks for your help guys. I have cracked it. I would have done as VBSCAB suggested however my process has a different PID each time it runs, so I don't see how I could.
Answered 11/29/2009 by: blade2
Blue Belt

Please log in to comment
0
Then I guess you have no choice but to use the Process Name unless anyone else can come up with a better solution. Here's an example, just replace the exe..



On Error Resume Next
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colProcessList = objWMIService.ExecQuery _
("SELECT * FROM Win32_Process WHERE Name = 'YourRunningApplication.exe'")
For Each objProcess in colProcessList
objProcess.Terminate()
Next


Make sure that terminating this process has no linkage to the others as mentioned by VBScab and Shakeela511
Answered 11/29/2009 by: PackageExpert
Blue Belt

Please log in to comment
0
I changed my mind. My mind was on process creation, as I'm building a script at the moment which creates and monitors a process's execution. For that, I need the process ID, as there may be another instance (or instances) running.

For process termination, it wouldn't matter if there's more than one instance since, if you need to kill Fred.EXE in order to replace it, you would clearly need to kill all instances of it.
Answered 11/30/2009 by: VBScab
Red Belt

Please log in to comment
0
One way of killing the process is to download PStool from Sysinternals & create a Transform containing a Custom Action VBScript which uses PSList & PSKill. The script should call PSlist to list all the processes to a file, parse the file to find the relevant Process Name and thus its Proces ID, and then call PSKill to kill that process ID.

To call the uninstall using the new Transform, check out my comments in http://itninja.com/question/can't-apply-transform-with-msi-reinstall.
Answered 11/30/2009 by: andys0123
Orange Senior Belt

Please log in to comment
0
Without question, command line tools, especially ones of quality such as those from SysInternals, work. However, they are more suited to one-off - what I call QAD (Quick And Dirty) - usage. For a more professional approach, script is the way to go, since to describe error-trapping and conditional branching in batch/command files as "primitive" would be more than kind.
Answered 11/30/2009 by: VBScab
Red Belt

Please log in to comment
0
Hence the VBScript just shelling out to run PSList & PSKill - not running from a batch file. Not an ideal solution, but it works exactly a required.
Answered 11/30/2009 by: andys0123
Orange Senior Belt

Please log in to comment
0
If the process (file) is installed by the package then I would also (before executing the kill) get the path of the file and use that in the wmi query to make sure the process is part of the package and not any "random" process.
Answered 11/30/2009 by: AngelD
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity