Since we announced the acquisition of .NET Reflector it’s been pretty quiet, or at least I imagine that’s how it seems from the outside. What we’ve actually been doing is collecting and sifting feedback, and familiarising ourselves with the source code, which has been remarkably easy given the amount of it there is thanks to Lutz’s awesome architecture. Jeff McWherter did some great work interviewing people about Reflector for us at this year's PDC as well.

We’ve had a lot of reports about problems with translation when decompiling source, and in fact the vast majority of bug reports we get about Reflector relate to this. At present I have some 3125 separate translation failure reports in front of me. Many of them are probably duplicates, but still, it’s clearly a big deal. I also suspect a lot of them are coming up whilst trying to decompile obfuscated code, which can cause problems because, if instruction reordering has occurred, the resultant IL tends not to be directly translatable into any .NET source language. We are aiming to improve translation support because we’d like to use it in some of our other products (more on this below), although at the moment it’s hard to say how much we can do with heavily obfuscated code.

There are also various other exception reports—hundreds of them in fact—but fortunately a good portion of them seem to relate to a few specific problem areas, which hopefully means they won’t be too hard to fix.

We’ve also had a raft of enhancement requests. The assembly list in particular seems to be ripe for improvement. Popular requests that spring to mind include sorting and grouping. We’d have to be careful though, because it would be very easy to lose the ability to run Reflector under the .NET 1.0 runtime. Also at the moment Reflector will run happily on Mono, which is again something we could lose if we start getting too fancy with the UI. I’m not really sure how big a deal these two issues are but, if you’ve got strong feelings about either of them, now would be a very good time to tell us.

In terms of major changes, at the moment we’re not planning anything. A lot of the kind of requests we get for these things are pretty niche, so we’re unlikely to take them any further. The reason for this is that we don’t want to pollute Reflector with what, for most people, would simply amount to bloat. If you’re interested in custom functionality I’d encourage you to write an add-in to deal with that. It’s actually quite simple to do, and the API that Lutz has provided is very nice indeed. There’s some great information on how to go about this on Jason Haley’s site at http://jasonhaley.com/Addins/. Peli de Halleux also has a tutorial on his blog at http://blog.dotnetwiki.org/ReflectorAddinTutorialBonusHelperClasses.aspx. I’d highly recommend both of these for getting started with add-in authoring: they’re what I used.

On a related note, there are no restrictions on creating commercial integrations if you’ve come up with something that provides the kind of functionality that others might want to use. TestDriven.NET by Jamie Cansdale, and Patrick Smacchia’s NDepend—see http://weblogs.asp.net/nunitaddin/default.aspx and http://www.ndepend.com/ respectively—are both notable examples of this approach.

However, before diving into the APIs, or formulating any grand schemes to make a zillion dollars with some killer piece of functionality, you should definitely check out the add-ins on CodePlex (http://www.codeplex.com/reflectoraddins) because you might find that what you need has already been implemented.

In terms of what comes next, we're currently figuring out how we can use Reflector’s technology in other products. For example, the next version of Exception Hunter will include Reflector’s decompilation capability, which will let you see exactly where exceptions are thrown even if you don’t have the source code for an assembly. We’ve already got this waiting in the wings; it just needs some testing and bug-fixing before we can put it out.

We need to put out another Reflector release in the next few monthts to deal with the expiry of the current version. The expiry is something that’s oft complained about, but I categorically deny all responsibility, but don't worry, we are thinking about easing the pain a little. This release will likely include some bug fixes but, with .NET 4.0 looming on the horizon, we'll need to do some more in-depth work as soon as Microsoft release something more closely approximating the final cut. Given the amount of effort involved there, I'd be gobsmacked if we didn't take the opportunity to engaged in a more general fix-fest as well.

For now, that’s all I have to say, but if you have any ideas or comments about any of this stuff, or you think I’ve missed something, please post below.