ILSpy: .NET Reflector Alternatives Redux
March 17, 2011 2 Comments
In my last post I discussed several possible alternatives to the soon-to-be-a-paid-app .NET Reflector. At the time, none of the options were entirely viable replacements, although ILSpy in particular showed great promise.
As ILSpy was in active development at the time, and was less than a month old, I thought it might be worth checking back in on that project. As it turns out, I didn’t need to wait this long, as Milestone 1 of ILSpy dropped a day after my post.
Now three weeks later, I took the latest build of ILSpy for a test drive. Visually, very little has changed. There are now a couple options that can be set, and an Analysis window is available (though I couldn’t figure out what it was supposed to do or show). C# and IL are still the only two language options for the decompiler output, even though I had read that VB was in the works. Still no support for plug-ins, but then I wasn’t expecting it. One feature that I thought was new was the ability to save the source for an entire assembly all at once, but I double-checked the previous version and it turns out that I’d simply overlooked the feature. (Still, it’s a nice feature).
What about the killer feature; the decompiler output? With the new version of ILSpy, I opened up the .NET 4.0 test assembly that I’d created for my previous tests. Once again, I focused on the more advanced features of the assembly; a method that uses LINQ and a method that uses a dynamic variable.
Just three weeks later, I’m pleased to report that the output of ILSpy is now quite comparable to .NET Reflector. The decompiler output of the method that uses the dynamic variable is very similar to .NET Reflector’s output (and neither is all that close to the original code). The output of the method that uses LINQ has been cleaned up as well. The .NET Reflector output is a bit closer to the original code (no Lambda’s), but both are quite clean. The body of the method in the decompiler output of both tools is two lines, which is the same as the original code.
In addition, I glanced over ILSpy’s decompiler output of the more basic elements of the test assembly, and found a few minor items that had been cleaned up.
A very impressive improvement in a short amount of time.
Last month I wrote that if you used .NET Reflector frequently and couldn’t live without, then you should pay for the upgrade. The alternatives weren’t adequate. I also advised occasional users to evaluate the alternatives and to keep an eye on their further development. I now think that even frequent users of .NET Reflector should give ILSpy a test drive. While still not complete, you might find that it meets your needs.