There are two reasons that I’m using log4net with increasing, rather than decreasing frequency, despite the excellent debugger in VS.NET:

1. When doing multithreaded programming, it lets me more easily see what threads are doing in parallel
2. Heisenberg’s Uncertainty Principle as it it relates to Properties

Let me expand on 2)… The Uncertainly Principle, simply put, states that the act of observation changes the observed. Now, he was talking about electrons, but when using the debugger in VS.NET this very principle can really come to bite you. The problem is that Properties do not have to be mere member variable accessors. They can have all sorts of logic attached. You may consider it bad form to have the act of observation (read: the getter) enact some sort of write behavior, and that is a position worth arguing. But even a simple “lazy load” put inside a getter can alter the behavior of the object if executed outside the normal flow.

And that’s precisely what happens when you start stepping into the Debugger. Unlike Methods, Properties are shown by default and therefore cause execution of the getter. So if you have a problem with some internal value not being properly set when you run your program, but it being set, if you step through it, look at your Properties.

Now, how does log4net help this? It’s still going to cause the getter to fire! Well, in some circumstances yes, but in many others, the reason you are getting this behavior is because the debugger fires all getters, not just the ones you want to look at, likely causing the problem via some part of code you really don’t want to be firing off at the time of observation.

Quite by accident, I just came across a useful syntax feature of using internal classes and interfaces: Partially exposing an internal class outside the containing assembly.

The basic pattern is this:

• Create your partially exposed class as internal
• Create an interface for the pieces of the class you want publicly visible and have the class implement the interface
• Create a public factory that returns your internal class cast to the interface.

I thought this would cause a compilation or at least runtime error, since your factory returns an internal class. But it doesn’t. It returns an object implementing the public interface. Since the underlying class is internal to its assembly, it can never be cast back to its originating type. The public members not exposed by the interface become virtually private. The nice thing is, that they are still public to classes that reside in the same assembly.

What is still funky is that you can take that object and call GetType and it will tell you the name of the internal type. You just can access that type.

Playing with this, i realized that the debugger can see all this quite nicely. It was then that i realized, that really, nothing is ever functionally internal or private. It’s all just semantics. With Reflection, you can poke around any object as much as you want.