I have been working a lot on a new developer tool, called Crack.NET. It is similar to Mole in that it allows you to walk an object graph on the managed heap, and similar to Snoop in that it injects itself into another .NET application and reports back information to you. It works for WPF applications, as well as Windows Forms applications.
However, on top of that functionality, I added in the ability to write and execute IronPython scripts that run inside the other application. Those scripts can do, well…pretty much anything. The possibilities are mind-boggling.
I wrote an article about Crack.NET and put it on the tool’s home page. The binaries and source code are available on that page, as well. Here’s the link:
I’ve been working non-stop on Crack.NET for almost 48 hours. Time for some sleep… 😀
Enjoy!!
Josh Smith on WPF 
I love it, its very slick indeed. See the other page for my other comments
Nice. Though, when I hear programmers say they coded X hours non-stop, I think of the episode of The Office where Dwight pees in the Slurpee cup.
It would be cool if the crack tool could do differential analysis. Load up a XAML file and kick butt. Wouldn’t be useful for apps you don’t control but still.
Great suggestion, John. I’ll add it to my TODO list.
Wow. Cool. 🙂 BTW, you are now #3 on Google search for Josh Smith… almost cooler than an NBA superstar. Maybe if you do this feature Google will freak and you’ll be #1?
I should probably bookmark your blog by now…instead of searching for it.
BTW, I saw Mike Brown mention VS Tools for Apps… it would be great if I could use PowerShell. I thought about adding such a feature to my app toolkit,, but licensing royalties worry me… especially when it is intended strictly for diagnostics on client machines.
[…] Introducing Crack.NET – Josh Smith releases Crack.NET, a tool which allows you to inspect and manipulate the managed objects in the memory of another process. Also it allows you to write scripts in IronPython and have them run in Crack.NET allowing you to do all kinds of manipulations. […]
Also, another idea:
Inspired by Tellurium UI Model Plug-in (TrUMP) tool for Tellurium… have it be possible to script tests. I actually use this concept in my own toolkit for quickly building regression tests..
Actually, possible is the wrong word. It is pretty much possible now. It should be EASY. Allow crack.net to specify command line arguments instead.
John,
I don’t understand what you’re getting at. Please explain the feature you have in mind in more detail for me.
Thanks,
Josh
First, rather than specifying what program to crack through Captive User Interface, expose command-line processing to Crack.Net. Showing off WPF is cool, but tools are meant to be injected without human intervention.
crackdotnet -WindowTitle “prism demo”
….loads crackdotnet , searches for top-level windows with title “prism demo”
crackdotnet -WindowTitle “prism demo” -Script searchForStudent.ps1
…infers language based on script extension.
The script could then use automation peers to drivethe UI to execute functional testing tasks.
Furthermore, you could use the UI to select element IDs you want to use to do testing.
However, care must be taken, since WPF has an extremely poor architectural flaw: disobedience of the open-closed principle, making xpath-lkike queries open to changes in templates.
John,
Thanks for the explanation. I see what you mean now. There are other features that I want to add into Crack.NET before I’d consider adding in what you’ve described. That feature does not currently “mesh” with my vision of the tool, but perhaps in the future it will.
Thanks,
Josh
Mole’s biggest weakness is that it wasn’t very MSBuild-like. You couldn’t command-line invoke. Do you use the PowerShell often? In my experience, Windows-only developers underutilize the command line.
Is your “vision” related to exploring WPF’s data viz. potential? If so, then I’m suggesting an orthogonal feature that will complement rather than interfere.
I used to do similar stuff with Beanshell and Java GUI libraries like SWT and Swing. It really helped keep me sane.
BTW… I hope I don’t sound like I’m trying to get you to budge. Just trying to teach you what I know, since you’ve taught me so much.
John,
I appreciate the teaching. I’ll think about what you’ve explained, and maybe it will gel with me eventually. And, no, I’ve never user PowerShell. I’m not sure what I’d use it for, to be honest.
Thanks,
Josh
Python and PowerShell both can serve as scripting languages, but there is a uniqueness to PS you don’t get with other scripting dialects: a paradigm shift. I’ll quote a comment from Slashdot I saved from over a year ago: “As I understand it, the difference between PowerShell and your typical Unix shell is that the Unix OS is built around the shell and PowerShell is built around the OS.”
I find it very convenient for many tasks, especially now that MS is releasing tools like SQLPS. SQLPS is a sandboxed powershell for sqlserver 2k8 — another cool feature of powershell.
I also find my scripts are easier to maintain, test, and write than bash, csh, or cmd, or even python. There’s also a great number of kickbutt community extensions: PSCX.
You may be scared by making such a paradigm shift, but think of the goodness WPF brought you by changing the way you think.
Oh, btw, I saw Paul Stovell mention he is working on PS extensions for WPF. That could be a tipping point to pique your interest. Perhaps Paul and you should discuss?
I certainly wouldn’t say that I’m “scared” of adopting different views. I just never met anyone who uses these tools who took the time to show me why they are so useful. Actually, Crack.NET is my first time ever using IronPython. Part of the reason I built Crack.NET is so that I would have a fun way to learn IronPython. Maybe once I get the feel for it, I will be more receptive to your feature suggestions. Until then, I’m still a total newbie in that department. 🙂
Josh
Sorry. I meant no disrespect about “scared”. I think you know what I mean though. I hear your frustration any time you shout back at someone who says WPF is over-engineered. (And I agree. If anything, WPF demonstrates how poor 90% of programmers are at OO Analysis, Design, AND Programming.)
Patterns are a good thing, but they must be understood before they can be used correctly, which increases the learning curve. There is therefore hesitation to transition to a better system.
To illustrate this point, at Boston.net ASG, someone asked those of us using WPF, “What’s the ramp-up time like?” I responded by saying it took me longer than most to get a demo that satisfied me (3 months), but my demo wasn’t ad-hoc, and clearly divides developer and designer roles, and had plans for cross-platform SL2/WPF 3.5 SP1 targeting. Others replied they had ramped-up in a week. To me, this just reminds me of Peter Norvig’s classical short essay, Teach Yourself Programming in 10 YEARS.