Should I always implicitly Dispose WCF Service Clients and Data Contexts?

Question

VS 2010 Beta Code Analysis is advising me to always dispose WCF Service Clients and Data Contexts for LINQ to SQL. Is this advisable? I assume this will eventually happen regardless. What are the pros/cons of doing so implicitly or not at all?

Answer 1

With anything that is IDisposable, it is your job to ensure it gets cleaned up promptly, to close open resources etc (connections, etc). So in short, yes. Finalizers only happen when GC kicks in, which can be a long time - and doesn't allow for the best pooling use etc.

Note however that WCF has a history of dodgy Dispose() implementations, making just using a bit hit-n-miss (you can lose the actual exception). Of course, it is also recommended to use WCF via async methods, which again makes it hard to use using; you'll often need to keep a reference and call Dispose() explicitely in the IO callback.

---

Re your comments; a few examples:

• SqlConnection: if you leave this hanging around (open) you prevent it reusing the connection from a pool; you can ultimately saturate the available connections this way, breaking your app
• GDI: IIRC, VS2005 itself (or 2003?) had a bug where an undisposed GDI object; GDI objects don't take much memory, so it didn't trigger GC, but it ran out of available handles and broke (this is a common bug in user code too, but more famous in an IDE)
• fail to dispose something like a FileStream: you've blocked your file system
• fail to dispose a TransactionScope and you've caused db (etc) blocking