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.

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

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.

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.

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

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

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.

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.
}

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

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

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.

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

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.

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

public Image LoadImage(String imageFile)
{
    try
    {
        return Image.Load(imageFile);
    }
    catch (OutOfMemoryException)
    {
        GC.Collect();

        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.

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.

• Using Linq to modify data, rather than just Querying.

• Deferred execution.

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

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.