• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1209
  • Last Modified:

Killing parent process without closing child process?

hi guys,

i have two application, application A is the main program and application B which is a little updater app. Now what i do is from my main application i run the updater app to check for updates and if one is found i basically overwrite application A with the new version.

my problem is that i cant have application A opened/running while i attempt to replace the file and hence need a way to close the application. i've been playing around with Process.Kill() however whenever i use it, both my applications close (i've read that as application B is opened by application A, A is B's parent and therefore calling Process.Kill() on A will close B as well as .Kill() terminates the entire process tree). what is the alternative to close A and keep B alive?

thanks
0
gem56
Asked:
gem56
1 Solution
 
raysonleeCommented:
   Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim job As System.Diagnostics.Process = New System.Diagnostics.Process()
        job.StartInfo.UseShellExecute = True
        job.StartInfo.Arguments += " /K TITLE Command Prompt"
        job.StartInfo.FileName = "c:\\windows\\system32\\cmd.exe"
        job.Start()
    End Sub

    Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
        Me.Close()
    End Sub
0
 
CodeCruiserCommented:
One option is to launch the update app. It checks to see if there is an update and updates the app and then launches it. If no update then it just launches the app. You can call it launcher rather than updater. Or  you can create another Launcher process which launches the updater first and then the app. This way, you wont have to make much modifications to existing code.
0
 
käµfm³d 👽Commented:
How are you launching the update app? Via Process.Start?

I wrote an update application some time back and my approach was to have the main application launch the update app via Process.Start. The update app would accept the path to the main app as well as the path to the updated exe (i.e. the location on the server), and the process ID of the currently running main executable. I compare the file versions of client and server; if the server is more recent, I would loop through the running processes on the client attempting to match the process ID that I passed on the command line. Once matched, I would kill that process (i.e. the main executable) and perform the copy. Once the copy completed, I had the path to the client executable, so I again used Process.Start and I relaunched the client.

This is dependent on not having multiple instances of the main app going, since the executable's file would be locked and prevent copying the updated version. You could modify this logic to account for multiple instances, though.

If you'd like to see the code I made I can post it, but I'll have to convert it to VB.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
gem56Author Commented:
hey guys, thanks for the replies.

@kaufmed: thats exactly the process im using...without restarting the application at the end after the update. in my main application i dim a new process, give it some processstartinfo values then process.start(). my updater then checks what it needs to and if theres a newer version on the server it'll download, unzip and prepare for an install. at this point it then attempts to process.kill() the main application to overwrite its files.

the absolutely puzzling thing is that yesterday when i was doing all this, whenever i called process.kill() both my main application and updater app would both close. after testing around and calling Process.GetCurrentProcess().ProcessName in both application, they both returned the exact same name (the name of the main application)...even though both .exe's are named differently. after googling around i read that when one process starts another, the second process will start "under" the calling process as if creating a process tree with the calling process being the root.

the confusing thing is that today when i ran the exact same procedure, it seems to work perfectly? calling Process.GetCurrentProcess().ProcessName now returns two different names (one being the main application name, the other being the updater application name). now im totally confused as im getting two completely different results with the exact same code?

any ideas?
cheers
0
 
hjgodeCommented:
Hello

I would try to Win32 API CreateProcess. Dont know what Process.Start() is doing in the background, but CreateProcess allows to run new independent processes: http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/ms684863%28v=vs.85%29.aspx

Here is a .Net wrapper for CreateProcess http://pinvoke.net/default.aspx/kernel32/CreateProcess.html

So, the updater exe is now a separate process.

The updater can 'kill' the main app the hard way or use some interprocess communication. You may use a flag file that is checked by the main app periodically or use a private message or event to inform the main app to shutdown itself. The updater can then re-launch the main app after updating files and then terminate itself.

Here is another example http://www.codeproject.com/KB/vb/autoupdate.aspx, if you use a internet search with "vb.net update exe" you will find some more.
0
 
gem56Author Commented:
champion, that works nicely, thank you :)
0

Featured Post

Configuration Guide and Best Practices

Read the guide to learn how to orchestrate Data ONTAP, create application-consistent backups and enable fast recovery from NetApp storage snapshots. Version 9.5 also contains performance and scalability enhancements to meet the needs of the largest enterprise environments.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now