Unreleased resources with WCF proxies not disposed before application shutdown?

I have a .NET application where I instantiate a WCF proxy which is held in memory till the application shuts down. Think of a singleton serviceagent that references the proxy, i.e. the proxy is reused for consecutive service calls. There are no exp开发者_如何学编程licit calls to proxy.Dispose() or using blocks.

The question is, am I leaking any resources? As far as I can tell, .NET garbage collection will prevent this from leaking memory (proxies are managed are they not?). Anything else - Network connections, ports etc?

edit: the item is not being held in another process outside of the application.

No. Once your application terminates, unless you've allocated global resources like shared memory/etc, Windows will close all your sockets and release all memory that was allocated to your program. If you think there's something akin to a leak, it may be because your program is not fully terminating (check Task Manager).

As soon as the application shuts down, anything in process will be reclaimed. Is this item being held in another process outside of your application?

Proxies are managed, but they may hold on to connections. That is why proxies implement IDisposable.

The general story is that if an object implements IDisposable, you should dispose it.

When your app terminates, the proxy is terminated along but any resources that it holds onto (such as open connections) are not terminated until the proxy is actually cleaned up by the garbage collector.

Long story short: Always call Dispose on disposable objects.

It is a recommended best practice to always close the proxy when the client is done using it. Closing the proxy releases the connection held toward the service, which is particularly important to do in the presence of a transport session. It also helps ensure the threshold for the maximum number of connections on the client’s machine is not reached.

For the singleton service closing the client proxy will terminate only the transport session, not the singleton context and the instance inside. If the singleton service supports contracts without a session, those contracts will not be per-call: they too will be connected to the same instance. By its very nature, the singleton is shared, and each client should simply create its own proxy or proxies to it. closing the proxies did not terminate the singleton.