What are the most common misunderstandings of how things work in .Net?

Question

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!).

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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";
}

Answer 10

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.

Answer 11

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.

Answer 12

The biggest one I've come across is when doing web forms in asp.net. 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.)

Answer 13

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

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

Answer 14

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, etc....to actually utilize it's full purpose.

Answer 15

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.