Remote Debugging the .Net Framework – not!

So I got a little excited when I saw how to debug the .Net Framework from within Visual Studio 2008. So I started the remote debugger on my Web-Server and attached to the process to debug some problem with my recent web-application. Next I choose to load the symbols of the .Net Framework to get my hands on the source of all evil – just to realize that I takes quite some time and then the web-server would just restart … that’s it. No debugging whatsoever 🙁

How is your token?

So after signing my newly created assembly I need the PublicKeyToken for various reasongs … so how would be the best way to get this?

One way would be to deploy the assembly to the GAC and then look at the properties – there you’ll find the token. a little more smooth is this approach:

sn.exe -T <AssemblyName>

This assumes you started a shell with your Visual Studio Tools in the path …

Debugging the CLR

Visual Studio 2008 offers this great feature to include the CLR in the current debug process. This is really great if you think you might want to dare to challenge the CLR for messing with your code!!

OK, so I dared the CLR … and I thought I’m a smart guy and place some breakpoints in the downloaded source-code of the CLR … but to my surprise they are never reached 🙁 The same applies, if you try to run the code up to the current cursor-position … this is also doomed to fail!

So if you’re worthy of debugging the CLR, you will have to go the whole nine yards and step thru every single line of code (or in my case go thru each iteration of a loop).

Who shall be tested?

In a time, where test-driven-development (TDD) is becoming an established way to write a software you naturally write tons of (unit-)testing-code (that’s why it’s called test-driven).

OK, so you define some functionality, which should be exposed by a certain component. So you will most likely have a couple of public methods supporting this functionality. To make sure everything works as expected you write your usual testing-code.

So far so good. So imagine you have a couple of public methods exposing your predefined functionality, and a whole lot of other (private) methods doing some helper-stuff.

During the testing phase you will suddenly find out, some tests are failing. The good developer you are, you have messages associated with your asserts, so will have a clue on why something went wrong. But still, you will have to digg into your code to find, that some helper-methode is all over sudden screwing your whole component.

At this point in time you might want to write tests for those helper methods as well, just to make sure these helpers work expected – just like you do for your public methods. But wait, there is a problem! Usually your unit-tests will reside in a separate assembly, so you will not be able to call those private helper methods at all. But fortunatly there is help on the way … using reflection you can circumvent this problem.

Fortunatly MbUnit has already built in support, for testing such kind of methods using reflection.

Let’s assume you have a class called BusinessClass with a private helper methode DoSomething, which takes a string as a parameter, does some processing and returns some other string. So an appropriate test would be:

using System;
using MbUnit.Framework;
using MbUnit.Framework.Reflection;
public class SampleTests
public void DoSomethingTest()
BusinessClass foo = new BusinessClass();
string output = (string)Reflector.InvokeMethod(AccessModifier.NonPublic, foo, "DoSomething", "my input string");
Assert.AreEqual("my output string", output);