开发者

Do I need to close a .NET service reference client when I'm done using it

开发者 https://www.devze.com 2023-01-06 22:40 出处:网络
I\'m trying to find out if it is neccessary to close a .net service reference client when you are done using it.Almost all of the examples that I have come across on the net don\'t seem to, but the cl

I'm trying to find out if it is neccessary to close a .net service reference client when you are done using it. Almost all of the examples that I have come across on the net don't seem to, but the client that is generated implements IDisposable and since it does open a connection to a service, my intuition tells me you need to close that connection when you are done with it.

Here is a code sample I pulled from http://msdn.microsoft.com/en-us/library/bb386386(v=VS.90).aspx :

private void button1_Click(System.Object sender, System.EventArgs e)
{
    ServiceReference1.Service1Client client = new 
        S开发者_C百科erviceReference1.Service1Client();
    string returnString;

    returnString = client.GetData(textBox1.Text);
    label1.Text = returnString;
}

I would think that you should at least call client.Close() at the end of this method, and better yet wrap the first line in a using statement. I just wanted to get some feedback on this to find out what the best practices are.


Yes, you do, but you need to be very careful when doing so. While closing anything that implements ICommunicationObject the potential exists to cause the disposal of the object to take an excessive amount of time in the event that there is an error or fault on the channel.

Because of this, it is prescribed that you call the Close method and then call the Dispose method on IDisposable, using a number of catches for certain exception types and calling Abort before you finally call Dispose.

You can wrap this logic up in an IDisposable implementation which you can use in a using statement.

The key here is to create a token that implements IDisposable and then in that implementation, call Close, catch the relevant exceptions, call Abort (if necessary) and then call Dispose.

This is implemented as an extension method which returns an IDisposable on it which in turn allows you to use it in a using statement.


Best practice is, if the class implements IDisposable, call Dispose() in a finally clause, or wrap it with using () { }

Edit
Following the @casperOne comment below, it seems WCF clients should be treated more cautiously. I didn't know that, and am a little unsettled by it, with using() having served me well thus far.


The best thing to do is look at the generated client code for Dispose() and see if it's really disposing of anything, like HTTP connections or something.

On one hand, it may just be that the interface it implements inherits from IDisposable because some client might need to dispose of something, even though that particular one doesn't. That's similar to MemoryStream, a class that implements IDisposable because all Streams do, but that doesn't actually deal with any unmanaged resources.

On the other hand, it never hurts to use using, even if Dispose() is an empty method. And MS examples are actually really bad about not using using even if they should (e.g. here), so don't take their example as good evidence that you don't need to.

0

精彩评论

暂无评论...
验证码 换一张
取 消