The Rock Star Hack of 2008

Hacks are usually the result of working around a bug or artificial limitation in some library against which you are coding, but have no ability to modify. I typically try to brush my hacks and workarounds under the rug, hoping no one will ever see them. But today I am proud to announce a hack I came up with. This is, in my opinion, one of the few hacks worth its weight in digital gold.

Karl Shifflett and I were talking on the phone yesterday. He mentioned that he has received a lot of support e-mails on moleproject@yahoo.com where people are confused about how to open Mole. Several people have tried to view an object in Mole that wasn’t “moleable,” meaning that the Mole.Visualizer.dll assembly is not decorated with an instance of the DebuggerVisualizer attribute where the target type is the type of object (or ancestor type) they want to molenate. In other words, people have been trying to open Mole on a business object they created, but Visual Studio does not list Mole as an available visualizer for that object.

Team Mole has known about this issue for a long time. The crux of the matter is that Visual Studio will not allow us to apply the DebuggerVisualizer attribute to Mole and specify that it works for any object that descends from System.Object. Visual Studio does not want to show Mole as an available visualizer for any type of object, but that is exactly what we want it to do. Yesterday I figured out a simple way to work around this artificial limitation imposed by Visual Studio. Karl has since dubbed it “The Rock Star Hack of 2008” since my nickname is Rock Star (more on that here).

Visual Studio has no qualms with allowing us to specify that Mole can be used to visualize a System.WeakReference object. Since WeakReference is basically just a thin wrapper around any object, we use WeakReference as a Trojan horse to smuggle any object past the Visual Studio sentries and into Mole. Once Mole gets a hold of the WeakReference we wrapped around the object that we actually want to visualize, it unwraps the object and displays it in the UI, throwing away the WeakReference in the process. Keep in mind that we are only using WeakReference as a container to smuggle any object into Mole, we are not using that class for its intended and documented purpose.

So that’s all well and good, but it would be a real nuisance if you had to stop your debugging session just to edit your code and create these WeakReferences for Mole, wouldn’t it? That’s where the Watch window enters the picture. You can create a WeakReference in the Watch window, and pass the object to visualize into its constructor. Here’s an example of how I used this feature to open Mole on Podder‘s main data model class instance:

Once the WeakReference has been created in the Watch window, I can simply click on the magnifying glass icon to open Mole. Bear in mind that this code is executing in the application’s data model assembly, which has no UI controls or anything else that you typically use to open Mole. Before this hack was invented, using Mole in this situation was impossible. How cool is that?!

Karl posted this video on YouTube showing how to use The Rock Star Hack of 2008:

You will need to get the new drop of Mole to perform the hack. The new drop also supports molenating Windows Workflow Foundation apps! Here is the link: http://karlshifflett.wordpress.com/mole-for-visual-studio/