Question

Quick question: One of my forms in my winform app (c#) makes an async call to a WCF service to get some data. If the form happens to close before the callback happens, it crashes with an error about accessing a disposed object. What’s the correct way to check/handle this situation? The error happens on the Invoke call to the method to update my form, but I can’t drill down to the inner exception because it says the code has been optimized.

The Code:

  public void RequestUserPhoto(int userID)
        {
            WCF.Service.BeginGetUserPhoto(userID,
                new AsyncCallback(GetUserPhotoCB), userID);
        }


    public void GetUserPhotoCB(IAsyncResult result)
    {
        var photo = WCF.Service.EndGetUserPhoto(result);
        int userID = (int)result.AsyncState;
        UpdateUserPhoto(userID, photo);
    }

    public delegate void UpdateUserPhotoDelegate(int userID, Binary photo);
    public void UpdateUserPhoto(int userID, Binary photo)
    {
        if (InvokeRequired)
        {
            var d = new UpdateUserPhotoDelegate(UpdateUserPhoto);
            Invoke(d, new object[] { userID, photo });
        }
        else
        {
            if (photo != null)
            {
                var ms = new MemoryStream(photo.ToArray());
                var bmp = new System.Drawing.Bitmap(ms);
                if (userID == theForm.AuthUserID)
                {
                    pbMyPhoto.BackgroundImage = bmp;
                }
                else
                {
                    pbPhoto.BackgroundImage = bmp;
                }
            }
        }
    }

UPDATE:

I still don't know where to go with this. What I really need here is a design pattern for making WCF async service calls from a win form that is elegant at handling form closes before the async call can return. The user is able to click the X on the form, or any form, at any time. The problem is much larger than the single example I shown above. My app actually makes hundreds of WCF calls, and I'm trying to figure out how to handle these gracefully, and in a consistent way throughout my application. For example, if I have to add a 100 lines of codes with ManualResetEvents or background workers, or mutexes, or whatever, for each WCF call just so it won't bomb my app, that's going to introduce a lot of room for error. What I need is a clean way to call a service asyncronously, and then convert it to a one-way call if the form happens to close. In other words, let the service finish running, but I don't care what the results are, and don't call the callback, because it isn't there anymore.

Answer 1

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.