3

I'm having a weird situation that I'm trying to understand. This piece of code is giving CA2000 (call Dispose on object before all references... ) :

var ms = new MemoryStream(Encoding.Default.GetBytes(DefaultControlTemplateXaml));
using(ms)
{
    var x = XamlReader.Load(ms);
    _defaultControlTemplate = x as ControlTemplate;
}

However, this other piece is not:

var ms = new MemoryStream(Encoding.Default.GetBytes(DefaultControlTemplateXaml));
try
{
    var x = XamlReader.Load(ms);
    _defaultControlTemplate = x as ControlTemplate;
}
finally { ms.Dispose(); }

As per Microsoft's documentation:

The using statement ensures that Dispose is called even if an exception occurs while you are calling methods on the object. You can achieve the same result by putting the object inside a try block and then calling Dispose in a finally block; in fact, this is how the using statement is translated by the compiler.

So I'm really at a lost here... aren't those two statements supposed to be identical?

Update

Since people insist (without reading my comment) on explaining the using ettiquete. I'll put it this way:

  using (var ms = new MemoryStream(Encoding.Default.GetBytes(DefaultControlTemplateXaml)))
  {
    var x = XamlReader.Load(ms);
    _defaultControlTemplate = x as ControlTemplate;
  }

This still gives CA2000 on fxcop, so the original question remains.

Update 2

Adding some screenshots so that you can see this is Visual Studio 2010 and the whole function.

First version (gives warning): With warning

Second version (ok): Correct build

Jcl
  • 27,696
  • 5
  • 61
  • 92
  • Of course, I know it's best practice to instantiate the IDisposable inside the `using` parenthesis, I put it before for making the statements as identical as possible. – Jcl Mar 16 '12 at 13:25
  • @xanatos: That was my thought too, but then I checked the C# language specification and it states that the object is created outside the `try` block. – Martin Liversage Mar 16 '12 at 13:34
  • It doesn't appear that VS2010 with code analysis (aka FxCOP 11) flags either as problematic, might be there is a bug in older FxCOP versions regarding this scenario? – Lasse V. Karlsen Mar 16 '12 at 13:35
  • @MartinLiversage On the argument http://stackoverflow.com/questions/3923457/is-cs-using-statement-abort-safe – xanatos Mar 16 '12 at 13:42
  • @LasseV.Karlsen I'm using VS2010 and getting the warning. – Jcl Mar 16 '12 at 16:10
  • @Jcl: I cannot reproduce a CA2000 warning for the first version in your Update 2 code. Are you perhaps running VS 2010 without SP1 or targeting a .NET Framework version other than 4.0? – Nicole Calinoiu Mar 19 '12 at 14:51
  • @Nicole, nope, this is SP1 targeting .NET 4.0... this must be a bug caused by something else. I've tested some isolated code like this on a different project and it does not issue the warning. I upvoted a [bug report on Connect](http://connect.microsoft.com/VisualStudio/feedback/details/469815/code-analysis-warning-ca2000-when-using-the-using-c-construct). – Jcl Mar 19 '12 at 20:54

3 Answers3

4

(Removed some stuff that didn't apply to the question and also some incorrect stuff about ThreadAbortException.)

You are probably experiencing a false positive reported by CA2000. You can search Microsoft Connect for CA2000. There exists quite a few issues (not all of them being false positive bugs).

I personally have turned CA2000 off in some projects because of these false positives. I'm using Visual Studio 2010 with Code Analysis and I just verified that, yes, after having to suppress CA2000 too many times we decided to turn it off in the project I'm working on right now.

Martin Liversage
  • 104,481
  • 22
  • 209
  • 256
  • 1
    But "using" doesn't solve the problem you mention at all. using" is not magical; suppose a ThreadAbortException happens *after* the resource is allocated and *before* the variable ms is assigned the reference to the object that holds the value. In that case *what can the using's finally block possibly do*? The variable was never initialized and so still has its default null value, and so the finally block cannot dispose it. The simple fact of the matter is that "using" is for *politeness*; it is for making a "good faith" effort to free the resource. This is why thread aborts are so bad. – Eric Lippert Mar 16 '12 at 15:00
  • @EricLippert Fxcop is supposed to analyze the code output, if Microsoft documentation (which I linked) says both statements produce the same output by the compiler, then I see no reason for one issuing a Code Analysis warning, and the other not issuing it :-( – Jcl Mar 16 '12 at 16:14
  • @MartinLiversage [This issue on Microsoft Connect](http://connect.microsoft.com/VisualStudio/feedback/details/469815/code-analysis-warning-ca2000-when-using-the-using-c-construct#details) sounds like the problem I'm having here. I can't seem to log in to Connect right now to upvote... I'll leave it like that for the time being and just use a try/finally (which I'm not against of... I was just trying to understand why it happened). Thanks, the link to Microsoft Connect was helpful – Jcl Mar 16 '12 at 16:51
  • @Jcl: I haven't got the faintest idea why FXCOP does or does not report any particular warning; you'll have to take that up with someone who knows something about FXCOP, and that's not me. My comment was not intended to address your question at all; it was intended to address Martin's incorrect assertion that a "using" block is robust in the face of thread abort exceptions; it absolutely positively is not. A "using" block in no way guarantees that a resource that has been allocated is actually freed; *the thread could have been aborted immediately after the resource is allocated.* – Eric Lippert Mar 16 '12 at 17:07
  • @EricLippert oh yes, I misread your comment as directed to my question, it makes much more sense now, I'm sorry about that. – Jcl Mar 16 '12 at 17:14
  • Accepted as answer since it does indeed seem to be a bug (which I upvoted and commented on Connect). Couldn't reproduce in other project with the exact same piece of code... something else must be causing it, but since that code should not (and does not) issue the warning, it must be a bug. – Jcl Mar 19 '12 at 20:55
0

There is a difference in the two pieces of code, that may be the reason for why FxCOP flags one but not the other.

Note that Code Analysis in Visual Studio 2010 Premium does not flag either piece of code with that warning, so there might be some understanding added compared to older FxCOP versions there.

Anyway, the difference is that in reality, the using block does not translate to the try/catch block shown in the question.

Here's a better translation:

var ms = new MemoryStream(Encoding.Default.GetBytes(DefaultControlTemplateXaml));
var temp = (IDisposable)ms;
try
{
    var x = XamlReader.Load(ms);
    _defaultControlTemplate = x as ControlTemplate;
}
finally
{
    if (temp != null)
        temp.Dispose();
}

Note that I'm not saying this is the reason for your warning, I'm just saying that's one difference between the two pieces of code.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
-1

The correct code would be

using(var ms= new MemoryStream(Encoding.Default.GetBytes(DefaultControlTemplateXaml)))
{
    var x = XamlReader.Load(ms);
    _defaultControlTemplate = x as ControlTemplate;
}

You need to declare and assign inside the using statement. Then, it will call dispose properly

Edit: Clarify the Reference problem

I assume you do the following:

var ms;
using(ms= new MemoryStream(Encoding.Default.GetBytes(DefaultControlTemplateXaml)))
{
    var x = XamlReader.Load(ms);
    _defaultControlTemplate = x as ControlTemplate;
}

then you could still use the ms variable after it has been disposed. That is what the Message is about. Or maybe you assign ms to another var inside the using block.

Max Keller
  • 372
  • 1
  • 10
  • I added that as a comment on the question, made it for readability. Same thing happens, CA2000 on fxcop (which is the original question). The object gets disposed correctly either way, I just don't like having that warning on fxcop. – Jcl Mar 16 '12 at 13:27