Stack OverflowWhat are the most common misunderstandings of how things work in .Net?
[+18] [17] Rob Levine
[2009-08-07 18:33:25]
[ c# .net common-mistakes ]

In your experience, what do you see (or hear) as common misunderstandings about how things work in .Net?

I'm not thinking of common programming mistakes, such as

throw ex

to rethrow an exception, but rather common misconceptions about how the framework works such as:

the [Serializable] attribute is required for xml serialization, or that the default object.GetHashCode() implementation somehow considers all private fields in your type.

One of the reasons I am asking this question is that I spend a lot of my professional time mentoring junior developers and I feel it is important to understand where the common misconceptions are. As someone who has used .Net for a long time I am guessing that there is a lot of knowledge I consider to be obvious, but actually may not be. I personally can't remember when I learnt the many nuances of how things work (and, of course, I'm sure I still have many left to learn!).

(1) why the markdown? Isn't this a reasonable question? - Rob Levine
(1) Rob, agreed, until somebody shows a link to a dup. - Henk Holterman
this is a duplicate, one sec... - Ed S.
(3) It isn't a duplicate of that. I am specifically not asking for common programming mistakes, I am asking for common misunderstandings. The sort of things that you don't pick up when reviewing code as a "mistake" but are common flaws in how people think it all works. - Rob Levine
(1) LFSR, that is a related but not a duplicate. - Henk Holterman
(4) Community wiki? - Anthony Mastrean
+1 I´m starting in C# and topics like this helps me understand better what (not) to do. - Luiz Damim
(1) I'm voting to reopen, this is about "misunderstanding .NET", not about "programming mistakes". It could yield some useful answers that are not programming mistakes. - Henk Holterman
I think it is a real shame this closed as a duplicate. The only similar one I found related to common programming mistakes. I specifically wasn't after programming mistakes. Why? Because I am not after tales of bad practice. I am trying to get an idea of common misconeptions about the framework. I spend a good deal of my professional life mentoring others and an understanding of the areas that are commonly misunderstood is important; it is definitely advantageous to get a view on things I that I think may be obvious, but actually aren't. Personally I feel you were over zealous closing this. - Rob Levine
(1) Rob, I think you can still Edit, try to make the distinction (from mistakes) a bit clearer. And check the Wiki mark, that may help a little. - Henk Holterman
I will do that Henk - thank you for the tip, it is much appreciated - Rob Levine
[+21] [2009-08-07 18:40:39] Reed Copsey

IDisposable and the way the garbage collector works. A common misunderstanding surrounds the purpose of IDisposable.

I often see people not understanding that calling Dispose() on an object does not release memory, and IDisposable does not (directly) have anything to do with memory usage.

(3) +1 and the related using(obj) { } will "clean up" obj at the end. - Rex M
If calling obj.Dispose() does not release memory, why whould we call it? - Luiz Damim
It's intention is to release unmanaged resources. This might be memory related, but could be some other type of resource. obj.Dispose() does not necessarily have anything at all to do with memory. It also has absolutely no effect on memory allocated by the CLR directly. - Reed Copsey
(2) The key word there is "unmanaged." I think that misunderstanding IDisposable is really a subset of not understanding the difference between managed and unmanaged - Robert Rossney
Why is there even an interface that specifies how the class have built its implementation? - Simon Svensson
[+20] [2009-08-07 18:59:43] Ed S.

Not understanding that everything is by default passed by value, even references. A copy of a reference is passed, not the original reference, unless of course you are using the 'ref' keyword:

class Foo
    public string Name;
    public Foo( string name ) { Name = name; }

void Main( )
    Foo f = new Foo( "Original" );
    ChangeRef( f );
    Console.WriteLine( f.Name );  // prints "Original";
    ChangeName( f );
    Console.WriteLine( f.Name );  // prints "Modified";

static void ChangeRef( Foo f )
    f = new Foo( "Modified" );

static void ChangeName( Foo f )
    f.Name = "Modified";

(2) Good call - I've come across this misunderstanding myself more than a few times. - Rob Levine
+1 And the related fallacy "passing a reference type by reference is pointless" - not if you've ever used double pointers it isn't... - MattDavey
[+13] [2009-08-07 18:58:50] annakata

One for - using an empty shell .aspx page for the codebehind where an HttpHandler would be appropriate. Not nearly enough people know about HttpHandlers.

(2) agreed. or they vaguely know about them but are scared of them as some really technical thing, and think they'd be overkill for any given problem. - Rob Levine
[+8] [2009-08-07 18:48:20] Henk Holterman

The (exact) meaning of reference-type vs value-type.

All too often the "Value types are allocated on the stack" description turns up.

To add my own description:

  • The main difference lays in the copy-semantics, not in the memory allocation. Stack/Heap do play a role in understanding it all though.

  • Value Types are allocated inline, as local variables (stack) or as fields/elements inside reference types (heap).

  • Instances of Reference types do not have a name, they can only be instantiated on the heap and are always accessed through references.

  • References are (behave exactly as) value types.

Some of the confusion may come from the double role the references play:

 int n = str.Length;  // A
 str = null;          // B

in A, str is indistinguishable from the object-instance, in B str is clearly just the reference.

[+7] [2009-08-07 18:51:29] John MacIntyre

More focused on ASP.NET specifically, is that Webforms has left many developers with the impression HTML only allows one FORM element per page.

this is kind of the reverse of the OP's question - the .net misunderstanding would be that more than one form was a simple and reasonable desire :) - annakata
[+7] [2009-08-07 18:53:14] Peter MacMurchy

String immutability, the symptom being usage of the '+' string concatenation operator.

(3) Hmmm, excessive use of '+' maybe - Henk Holterman
Using + in a loop would be an example of excessive, since it churns memory much more than StringBuilder appends would. - Steven Sudit
Depends on the loop! Sometimes people are far too quick to switch to a StringBuilder when actually string concats would be faster. Generally a StringBuilder is only worth the hassle if you're doing more than 10 concats. - MattDavey
[+7] [2009-08-07 19:40:52] ScottE

The page lifecycle, especially with the use of master pages.

The key is how 4,5 and 6,7 are not what you'd expect!

  1. Content page PreInit event.
  2. Master page controls Init event.
  3. Content controls Init event.
  4. Master page Init event.
  5. Content page Init event.
  6. Content page Load event.
  7. Master page Load event.
  8. Master page controls Load event.
  9. Content page controls Load event.
  10. Content page PreRender event.
  11. Master page PreRender event.
  12. Master page controls PreRender event.
  13. Content page controls PreRender event.
  14. Master page controls Unload event.
  15. Content page controls Unload event.
  16. Master page Unload event.
  17. Content page Unload event.

(7) yak, thankfully we now have mvc - redsquare
[+6] [2009-08-13 04:59:53] Ronnie

Not knowing that Response.Redirect throws an exception when calling it.

try {
   if (1>0)
catch {
  //Response.Redirect throws an exception 
  //to stop the current thread.

(1) +1, this can be really useful to understand when debugging.. - Preets
(1) +1 LOL, I am sure I have made this silly one before - leppie
+1 luckily I've always found .NET to fairly light on these "WTF" moments. But then again I've never worked with Webforms in any great detail - MattDavey
[+4] [2009-08-07 18:54:28] Developer Art

That an operation on a string modifies that instance.

string s = "Bob & Lis";
s.Replace ("Lis", "Jenny"); // Won't modify the string but return a modifed copy

s = s.Replace ("Lis", "Jenny"); // Now we have it

[+4] [2009-08-07 18:43:41] Henk Holterman

A very basic thing: the distinction between an object and the reference(s) to that object.

Just incase your still confused - SwDevMan81
I gave up being confused some time ago. - Henk Holterman
[+2] [2009-08-07 19:10:49] Joshua

Not understanding the nuances when passing between gc managed objects and explicitly managed objects or when this state flips. In Winforms, a control is memory managed until its handle gets created, then is explicitly managed until OnHandleDestroyed at which point it is gc managed again.

Yes, it has a .Dispose() method. No, you are not guaranteed it gets called. No, you are not guaranteed that its constructor will be balanced with an OnHandleDestroyed call. Set up explicitly managed objects and subscribe to events in OnHandleCreated(), drop them in OnHandleDestroyed(), any other thinking -> MEMORY LEAK or worse.

[+2] [2009-08-07 19:52:11] Nick

The biggest one I've come across is when doing web forms in A developer will create a class member variable and set it on page load, but then when they are doing processing in a button click event they scratch their head as to why that variable is now null. They don't understand that http is stateless that they have to explicitly keep the state of their variables some place(viewstate, querystring, etc.)

[+1] [2009-11-03 16:45:34] Konamiman

The false idea that Visual Basic .NET and C# are completely different technologies, while actually both are languages based on the .NET framework and at the end it does not matter which one you use.

(2) It doesn't matter which one you use as long as it's not VB. - Dan Finch
[+1] [2012-02-20 16:59:50] MattDavey

Perhaps not very common but I once came across this little beauty

public Image LoadImage(String imageFile)
        return Image.Load(imageFile);
    catch (OutOfMemoryException)

        return Image.Load(imageFile);

What the author didn't realize is that the CLR automatically invokes a full collection before throwing the exception. When .NET says you're out of memory - you really really are.

PS. This was a WINCE app so memory usage was an issue.

[+1] [2009-08-07 18:48:05] NerdFury

Something that I see, is that there doesn't seem to be an understanding of the stack and the heap that is essential to how memory works in an application. The idea of a Value Type and a Reference Type seem to be known, but the difference, in terms of how the stack and the heap come into play is not understood.

I think this is due to the lack of pointers and garbage collection. Still, I think it's a core concept to anyone programming any OO language.

(3) I don't see it as a concept in OO. I find it a concept in C#. - Dykam
(1) The stack and heap is an implementation detail, there's no guarantee that value types will be allocated on the stack. - Simon Svensson
What about references? They are neither reference types nor value types, and can be anywhere (stack, heap, register) - MattDavey
[0] [2012-03-31 17:33:56] Sandeep
  • Using Linq to modify data, rather than just Querying.

  • Deferred execution.

  • Assigning object to null, makes it eligible for Garbage Collection.

[0] [2009-11-03 16:31:33] xxmrlnxx

Many people feels as though they can type .whatever and make anything happen. But to quite the contrary you actually have to know the inner workings of classes, properties, design, platform, actually utilize it's full purpose.