So I’ve been doing a lot of C#.NET lately and found one of the coolest tools ever earlier this week: Microsoft Moles. Seriously, this stuff is awesome.
The name’s a little strange. I mean, come on, when’s the last time you used the word “mole” in a good way? And when’s the last time you used it more than 25 times in a day? Yeah, that’s what I’m thinking, but still, the sacrifice of saying “mole” that many times is more than worth the power of this tool.
I’m not going to get into how to use Moles because there are all sorts of great resources for that. The one I found the most useful by far was over on Didactic Code by Dave Fancher. His article is excellent and I highly recommend reading it before beginning to use Microsoft Moles.
The main reason I’m posting is to share my rather troublesome experience getting started with Microsoft Moles. By default, the Moles “compiler” (moles.exe) will use multiple threads to reduce the overall time it takes to create the stub and/or mole assemblies. This can lead to a significant time savings because generating these assemblies takes a fair amount of time. Even when you restrict the framework to generating stubs or moles for only those classes you absolutely need it can grind for a good bit of time (15-30 seconds per assembly…that’s an eternity when working on a small solution). Obviously, multithreading this costly operation is an awesome built-in feature.
That is to say, when it doesn’t crash.
But that’s exactly what it did to me. Not all the time, but 90% of the time when you executed a build moles.exe would crash. It left Visual Studio in a confused state until you went and manually killed the moles.exe process. Seeing as how Moles was just replaced by the built-in Fakes framework in Visual Studio 2012, I didn’t see much point in trying to find a patch. The Microsoft Moles site tells you point-blank that Moles is no longer developed. Oh well, sucks to be me here in a shop still using Visual Studio 2008…!
Or maybe not. Maybe I could isolate the issue…perhaps its the fact that it’s running in Visual Studio? So I tried running straight from the command line and received the same result. To further narrow down the possible causes, I kept editing the “moles.args” file which VS produces in the obj\Debug\Moles folder. I started removing the CLR specifications first to no avail. Then the multiple references (this project I was working on had a lot of those). No dice. Finally, I started removing the number of mole assemblies being built until I got it down to one. Bingo! Success every time.
OK, so things will work if I’m only producing one mole assembly at a time. But it just so happens I’m not doing that…I’m building seven of them to support these unit tests. As soon as I add two, my chances of not crashing fall from 100% to less than 10%. I don’t care what the stakes are, those odds are horrible. That’s when I started looking into the moles.exe arguments and found the ProcessCount argument (short form, “/pc”). Per “moles.exe help compilation” ProcessCount “[s]pecifies the number of concurrent processes to generate Moles”. I figured it couldn’t hurt…let’s try setting “/pc:1” in the moles.args file. After this much digging, I can hardly say I was surprised when it worked! Multithreading might not be such a good idea afterall!
(My sarcastic tone here may imply I’m ungrateful to all those who’ve done research and development for Microsoft Moles. Let me state in no uncertain terms that this could not be farther from the truth. Such a minor issue in my book should not be held against a tool of this power. Moles has forever changed how I will approach Unit Testing in .NET and I plan on using it and its companion Fakes framework for years to come.)
So how can we get back into Visual Studio 2008 with the “/pc:1” argument set? I’m not sure if there is a better way, but here’s how I did it. I edited the “C:\Program Files\Microsoft Moles\bin\Microsoft.Moles.targets” file and changed one line. Inside the <GenerateMoles/> tag (the file is XML) there are several attributes. The one to change is CommandLineArguments. (Changes are highlighted in yellow.)
Sure enough, compilation of the moles assemblies in Visual Studio no works like a charm. Sure, it’s a little slower, especially the first time around, but it’s a small price to pay for stability. And that stability gives me a power now I only ever dreamed would be possible. Yes, Test Driven Design is absolutely key and approaches like MVVM help promote good unit test architecture. But at the end of the day it’s going to be a long time before everyone is doing it the “right way”. Until then, a tool like Microsoft Moles will forever be awesome. I mean, come on, hard coding a return value for System.DateTime.Now…how cool is that?
Till next time,