Thoughts on JustDecompile compared to Reflector

If you are a .NET developer, then you probably noticed that Telerik recently released a new decompiler - JustDecompile. It is a direct competitor to ILSpy and Reflector, although it has some distinctive differences that set it apart from the crowd.

Currently, it is in its beta stage, so be aware that if you test it - there might be problems, depending on assemblies you are working with.

NOTE: I am comparing JustDecompile to the free version of Reflector (version 6).

First, I must mention that the startup time is a bit slower compared to both Reflector and ILSpy. Not significantly, but it can be noticed. General performance for type analysis and decompilation is also a bit worse compared to Reflector. I hope there will be some optimizations made for the final release.

NOTE: JustDecompile also relies on Mono.Cecil.

Once the app starts, I was surprised to see an UI that is extremely similar to the one used in Reflector.

In case you were wondering whether it is possible to load the default set of assemblies tied to a specific .NET Framework, it is possible - all you have to do is click the small arrow on the top right, and you will see a Load Frameworks button.

The current choices are limited to .NET Framework 2.0, 3.5, 4.0 and Silverlight. For other .NET subsets (e.g. Windows Phone SDK based assemblies), you will have to add the assemblies manually. The good thing is, though, that you are able to create and load custom assembly lists.

Perfect for those who build their own frameworks and for those who are using custom-built assembly sets.

A future that is missing is the ability to analyze dependencies for a specific assembly. Reflector had it for quite a while and it is really helpful to see what additional requirements might be needed for a specific call to work.

JustDecompile, however, has a more than decent usage inspector.

I really liked the ability to directly search through multiple nested types, including the ability to analyze properties by their read/write invocations inside analyzed assemblies. The results are organized in a way that makes it easy to instantly see the parent assembly and cross-references.

A feature that I like and I think it will help JustDecompile in the long run is the ability to re-create projects from imported assemblies - something that Reflector had implemented through a plug-in. This component's stability is what I find most important - I am yet to crash the decompiler by trying to create a custom project.

That being said, I should also mention that the sole fact of creating a "recovered" project does not mean that the project will instantly be in a buildable state. For built-in .NET libraries, there will be multiple conflicting members that will require the developer to work on refactoring the code (read: fix naming, mostly).

NOTE: The current beta only supports exporting to .csproj (C# project).

Besides the UI, there is also the command-line version of JustDecompile, located in the local application folder (wherever you decided to install it). Unlike its visual counterpart, it is only used to create a .NET project based on an assembly that is passed to it as a parameter. I can already see how this can be coupled with PowerShell and third-party applications to make project export much more efficient for large assembly stacks.

Overall, JustDecompile is on the right path. There is still work to be done, but most of it is revolving around "bonus" features - the most important components are already working pretty well (not guaranteed for everyone, given the state of the release).

To summarize, here are some points JustDecompile needs improved:

• Performance - everywhere, from starting seconds to internal decompilation performance.
• Visual Studio plugin - necessary for fast type analysis.
• Dependency analysis
• Plug-ins - code analysis can be taken to a completely different level with the help of outside developers (e.g. analysis based on various indicators for the loaded assemblies).
• Support for multiple language project export - currently only works for C#. I know that this will surely be fixed in the final release (at least for VB), but again - this can be done through plug-ins, in case the guys from Telerik are not interested in supporting other .NET languages out-of-the-box (e.g. IronRuby, F#).
• Pre-defined assembly list repo - just for those popular SDKs, like MVVMLight, Windows Phone SDK, .NET Micro Framework and what not. Would be great to actually have the library lists downloadable and in case I have the given SDK installed, I can easily see what's inside it. As a bonus - NuGet integration for missing assemblies.