using-statement

In my DAL I write queries like this: using(SQLConnection conn = "connection string here") { SQLCommand cmd = new ("sql query", conn); // execute it blah blah } Now it just occurred to me that I am not explicitly closing the SQLCommand object. Now I know the 'using' block will take care of the SQLConnection object, but will this also take care of the SQLCommand object? If not than I have a serious problem. I would have to put in the 'using' on the SQLCommand on thousands and thousands of lines of code or do a cmd.Close() on hundreds of methods. Please tell me that if putting in the using or

C# has the using statement, specifically for IDisposable objects. Presumably, any object specified in the using statement will hold some sort of resource that should be freed deterministically. However, it seems to me that there are many designs in programming which have a single, definite beginning and end, but lack intrinsic language support. The using construct provides an opportunity to use the built in features of a code editor to, at least, clearly and naturally highlight the scope of such a design or operation. What I have in mind is the sort of operation that frequently starts with a

i have to review a code made by some other person that has some memory leaks. Right now i'm searching the disposable objects to enclause them with the using statement and i would like to know if there is a quick way that tells you all the disposable objects declared in. I mean something like resharper or another visual studio plugin. thanks. Neil Barnwell I know what you mean. I don't know, but look at FxCop. It might have a rule in there somewhere that checks whether objects implementing IDisposable are not disposed. Just a hunch, mind. UPDATE : Mitch Wheat writes: FxCop includes the rule,

Suppose I have the following: using(var ctx = DataContextFactory.Create(0)) { ... Some code ... } Why not just do the following and lose a couple of curly braces?: var ctx = DataContextFactory.Create(0); ctx.Dispose(); Thanks for the advice! The first is better. It ensures it is disposed even if an exception is thrown, and it correctly handles the case where Create(0) returns null (i.e. it doesn't attempt to call Dispose() on a null instance). Trevor Robinson A using statement is always better because... you can't forget to call Dispose() , even as the code evolves into different code paths

Having a mental block today, need a hand verifying my logic isn't fubar'ed. Traditionally I would do file i/o similar to this: FileStream fs = null; // So it's visible in the finally block try { fs = File.Open("Foo.txt", FileMode.Open); /// Do Stuff } catch(IOException) { /// Handle Stuff } finally { if (fs != null) fs.Close(); } However, this isn't very elegant. Ideally I'd like to use the using block to dispose of the filestream when I'm done, however I am unsure about the synergy between using and try/catch. This is how i'd like to implement the above: try { using(FileStream fs = File.Open(

When using a memory stream in a using statement do I need to call close? For instance is ms.Close() needed here? using (MemoryStream ms = new MemoryStream(byteArray)) { // stuff ms.Close(); } No, it's not. using ensures that Dispose() will be called, which in turn calls the Close() method. You can assume that all kinds of Streams are getting closed by the using statement. From MSDN : When you use an object that accesses unmanaged resources, such as a StreamWriter, a good practice is to create the instance with a using statement. The using statement automatically closes the stream and calls