Handling closing of WPF application

[MattNorman]

I am currently having issues whereby network ports stay in a listening state after I exit my application.

Currently I just have an exit button on the main window and shutdown all of the network elements as part of the command binding for that button.

On occasion, when re-loading the app I get network exceptions as the port I am trying to listen on is still in a listening state from the previous instance of the app.

Strangely, if I use command prompt to find the process ID and try to kill it, windows states that the process does not exist.

Is there a global event I can use to make sure my shutdown code is properly executed or a more consistent way to stop listening on ports?

I am using the old NetworkComms.Net library and this comes with built in methods to close all connections and shutdown all network elements.

 

[MattNorman]

I did some testing with a WinForms app and cannot re-produce the issue there. The port closes without fail on both button click and quitting the app.

Not sure what the difference is with WPF.

 

[MattNorman]

Managed to resolve the issue.

My app open a few other apps for certain features and it seems they were created as sub processes of my app. The network connections weren't closing whilst the sub processes were still running.

 

[Skydiver]

There is no difference in the way WPF or WinForms launches child processes since neither WPF not WinForms code does that launching. It will be the same .NET Framework or .NET Core framework code that launches child processes using the Process class. Furthermore, the Process class is just a thin wrapper around the Win32 ShellExecuteEx() API.

I suspect what are you seeing is the default behavior of the OS with regards to Windows sockets where they linger for a little while. Or at least I think it is standard behavior based on some of the NetMQ and ZeroMQ questions I've seen and that responses by people with a lot of Windows networking experience.