Karl and Andrew have taken Mole to the next level. Now you can edit properties and fields of an object, and those modifications are persisted! I was only marginally involved with this new feature, mostly testing and giving feedback, but I’m really glad that those two guys took the time to see it through to completion. This is really amazing stuff, and I highly recommend you check out the new article and download the latest bits. Here is the new article:

I performed some stress testing on Woodstock today, and found a couple of weak points in the code which prevented it from working well with absurdly large visual trees. By “absurdly large” I am referring to a visual tree with at least 10,000 elements in it. Huge, huge, huge visual trees. It should not be too often that a WPF user interface has a visual tree of that immense size, but I wanted to be sure that Woodstock can handle it well (up to a certain point).

The two performance enhancements that I addressed are:

1) Nodes in the TreeView are now loaded on-demand. When you expand a node in the TreeView it then loads the children of that node, if they are not already loaded. This drastically reduces the load time for the Woodstock window when your visual tree has thousands of items in it.

2) The children of a WpfElement are now temporarily removed from its Children property, just prior to that element being sent over to the debuggee process to be populated with property information and a snapshot image. When the freshly populated WpfElement is returned back to the visualizer its child elements are added back to its Children property. This can cut down the amount of time it takes to get the property information and snapshot for a WpfElement, especially if that element has a very large number of descendant elements.

It dawned on me that I can lazily load the element property information and snapshot images, by having two-way conversations between the debugger and debuggee processes, just by using the standard Visualizer API! This means that the whole timeout problem is gone, because a huge amount of data is no longer being serialized all at once. And, this enabled me to add in support for viewing snapshot images of every element in the tree, not just the one you initially selected!!

I added a thorough explanation of how all this works to the article in the “Lazily Loading Element Information” subsection, under the “How It Works” section. I’m so glad that I finally resolved this crippling issue. Now Woodstock is a truly reliable, robust, fast, and dependable WPF debugging tool.

The only remaining issue that I know of is if you let it run for a long time. Eventually a RemotingException is thrown while some GDI+ code is executing, and the visualizer crashes. I don’t think there’s a way for me to work around that bug…

I just published an article to CodeProject which makes my Woodstock debugger visualizer available to the world. Woodstock is like a miniature version of Snoop, which runs in Visual Studio when you are debugging WPF applications. It allows you to view the visual tree and all properties on any element. I think it is a very useful debugging tool for WPF developers, so I highly recommend checking it out. Learn more about it here: