C# async callback on disposed form

Answer 1

You're giving the callback an address to hit when the operation is done. The address is invalid when you close the form and hence you're getting this error. You need to build in a way of determining if you have an outstanding call before allowing your form to close.

I'd research the BackgroundWorker class. I'm sure you can still setup a crash by closing your form before the callback has fired, but with the BackgroundWorker, you should be able to interrogate it's status and handle your situation more gracefully.

You should not let your form close while the Async call is still active. Using BackgroundWorker, you can easily determine if the Async call is active.

Answer 2

public void UpdateUserPhoto(int userID, Binary photo)
{
  if ( Disposed || !IsHandleCreated )
    return;
  if (InvokeRequired)
  ...

Answer 3

I believe that there is an IsDisposed property on the Form object. You could check that property before calling Invoke.

Answer 4

Create a flag, something like "IsWaiting" as a ManualResetEvent (or even a simple bool), set it to true and only set it to false when your async result returns.

In your class dispose method put in a check for the flag, and only dispose the object once the flag has cleared. (Put in a timeout, just in case there's an error)

Answer 5

I got a lot of good comments on this question, but no good pattern that I can use throughout my application. I am posting here what I ended up doing as my answer, and hopefully it will help someone else down the road.

The WCF proxy that is automatically generated creates sync call methods, async methods using the begin/end pattern, and event based delegates using a Completed event. The example I posted above in my original question used the Begin/End pattern. The problem is that when the callback is made, you will have to do an Invoke to access your UI thread. If that UI thread is not there anymore (I.E. the user closed the window), you've got problems. The new event based pattern, automatically finds its way back to the UI thread, and from my testing, I have not been able to make it crash by closing before the service can complete. I guess the proxy is smart enough to NOT call the completed handler if the memory address does not exist? Or maybe it hangs onto a memory address to the handler, so it won't be garbage collected? So all you have to do is add a Completed event handler, fire off your call etc, servicenameAsync(), and wait for it to return to your handler (on the UI thread). I also, just to make sure, wrapped my completed handlers in try/catch blocks to handle ObjectDisposedExceptions, if any.

The main thing now: IT DOESN'T CRASH.

One gotcha (at least for me)... I was using a singleton pattern to access my WCF service. The problem with this is that it creates a static reference to your WCF proxy, used throughout your entire application. Sounds convenient, but when you are appending event handlers to the Completed events right before you make your async call, then those can get duplicated, triplicated, etc. Every time you make the call, you add ANOTHER completed event handler in addition to the one already added to your static WCF proxy. To solve this, I started declaring a new proxy clients for each call, or if multiple calls are not made per winform class, per each winform. If anyone has any comments on this or a better way, PLEASE let me know! The biggest problem with the singleton pattern is that if you have multiple windows open at the same time (different classes) that call the same async method, but you want them to return to different Completed handlers, you can't do that.