What is the minimum knowledge of CLR a .NET programmer must have to be a good programmer?

Question

When we talk about the .NET world the CLR is what everything we do depends on. What is the minimum knowledge of CLR a .NET programmer must have to be a good programmer? Can you give me one/many you think is/are the most important subjects: GC?, AppDomain?, Threads?, Processes?, Assemblies/Fusion?

I will very much appreciate if you post a links to articles, blogs, books or other on the topic where more information could be found.

Update: I noticed from some of comments that my question was not clear to some. When I say CLR I don't mean .Net Framework. It is NOT about memorizing .NET libraries, it is rather to understand how does the execution environment (in which those libraries live on runtime) work.

My question was directly inspired by John Robbins the author of "Debugging Applications for Microsoft® .NET" book (which I recommend) and colleague of here cited Jeffrey Richter at Wintellect. In one of introductory chapters he is saying that "...any .NET programmer should know what is probing and how assemblies are loaded into runtime". Do you think there are other such things?

Last Update: After having read first 5 chapters of "CLR via C#" I must say to anyone reading this. If you haven't allready, read this book!

Answer 1

Updated: reading the relevant parts of the book CLR via C# by Jeffrey Richter..this book can be a good reference..

Answer 2

Most of those are way deeper than the kind of thing many developers fall down on in my experience. Most misunderstood (and important) aspects in my experience:

• Value types vs reference types
• Variables vs objects
• Pass by ref vs pass by value
• Delegates and events
• Distinguishing between language, runtime and framework
• Boxing
• Garbage collection

On the "variables vs objects" front, here are three statements about the code

string x = "hello";

• (Very bad) x is a string with 5 letters
• (Slightly better) x is a reference to a string with 5 letters
• (Correct) The value of x is a reference to a string with 5 letters

Obviously the first two are okay in "casual" conversation, but only if everyone involved understands the real situation.

Answer 3

Jon's answer is good. Those are all fairly basic but important areas that a lot of developers do not have a good understanding of. I think knowing the difference between value and reference types ties in to a basic understanding of how the GC in .NET behaves, but, more importantly, a good understanding of the Dispose pattern is important.

The rest of the areas you mention are either very deep knowledge about the CLR itself or more advanced concepts that aren't widely used (yet). [.NET 4.0 will start to change some of that with the introduction of the parallel extensions and MEF.]

Answer 4

The minimum is... you deliver what you have been asked for within agreed time slot...

But real answer is that you must memorize minimum half of the .Net Framework 2.0 and quoter of 3.0. Otherwise you are bad .NET programmer.

Did it help?

Greets Mariusz

Answer 5

Should know about Memory Management, Delegates

Answer 6

Jon's answer seems to be pretty complete to me (plus delegates) but I think what fundamentally seperates a good programmer from an average one is answering the why questions rather than the how. It's great to know how garbage collections works and how value types and reference types work, but it's a whole other level to understand when to use a value type vs. reference type. It's the difference between speaking in a language vs. giving a speech in a language (it's all about how we apply the knowledge we have and how we arrive at those decisions).

Answer 7

One thing that can be really tricky to grasp is deferred execution and the likes.

How do you explain how a method that returns an IEnumerable works? What does a delegate really do? things like that.

Answer 8

A great programmer cannot be measured by the quantity of things he knows about the CLR. Sure it's a nice beginning, but he must also know OOP/D/A and a lot of other things like Design Patterns, Best Practices, O/RM concepts etc.

Fact is I'd say a "great .Net programmer" doesn't necessary need to know much about the CLR at all as long as he has great knowledge about general programming theory and concepts...

I would rather hire a "great Java developer" with great general knowledge and experience in Java for a .Net job then a "master" in .Net that have little experience and thinks O/RM is a stock ticker and stored procedures are a great way to "abstract away the database"...

I've seen professional teachers in .Net completely fail in doing really simple things without breaking their backs due to lack of "general knowledge" while they at the same time "know everything" there is to know about .Net and the CLR...