Take a free trial and find bugs in 3rd party components, libraries, frameworks, and any code where you don’t have the source.
A little while ago, I got an email from Ben, who’d been using .NET Reflector. We’d asked how his trial was going, and he told us about how Reflector let him drill down to a problem in 3rd party code in no time at all. It’s great to learn more about how the tool is being used, so we invited Ben to give us a little more detail:
The bug: When attempting to update .NET Reflector’s Visual Studio extension, the installation fails with a message “The certificate for a digital signature in this extension is not valid.” This is a Microsoft bug and is detailed here: http://support.microsoft.com/kb/2581019
What causes it: (From the link above) this issue occurs because Windows XP and Windows Server 2003 handle the Certificate Revocation Lists (CRL) differently than other operating systems.
When Extension Manager handles the Certificate Revocation Lists (CRL), Extension Manager uses the same method for all operating systems. However, Windows XP and Windows Server 2003 handle the Certificate Revocation Lists (CRL) differently than other operating systems. Therefore, issue 2 occurs.
We’ve heard that some of you are having problems with 7.5 at the moment. So rather than make you wait for us to finish 7.6, we thought we’d put out fixes for some of the more common issues. These include but aren’t limited to:
Reflector not working well with other visual studio add-ins and swallowing the Outlining > Collapse to Definitions command. This issue was particularly plaguing users who also had Coderush installed.
Visual Studio Crashing when debugging with the add-in installed, particularly when attempting to step into or over.
Problems installing the Visual Studio Package. Users were reporting a variety of largely generic errors in forum posts. We think we’ve fixed the majority of these cases but we would obviously like to know if you encounter any issues in this area.
The new build is live on the site and available to download right now.
Do let us know if you have any problems, and feel free to try out the EAP if you want to see what’s coming up in the next release of Reflector.
Today we are proud to announce the release of .NET Reflector v7.5. This release brings several enhancements to our Visual Studio integration, as well as improvements to the stability, performance, and design of Reflector itself. The new features allow developers to decompile, debug, and understand any .NET code within Visual Studio, using Visual Studio’s native debugging workflows.
It’s our first release of 2012, and it’s a leap year, so we’re jumping right ahead to EA build 7 (we actually released build 6 quietly over the holidays, but a lot of the work was preparation for Build 7). We’ve been focusing on fine-tuning our integration with Visual Studio, as well as making the best use of our resident UX specialist. We released this at the very end of last week, so the dust has settled, the post-it notes have all been moved, and now is a good time to take a look at the latest enhancements.
The previous few builds have been about making the Visual Studio integration more seamless and morphing from being a Visual Studio Add-in to a Visual Studio Package. The whole team is working towards making seamless, dynamic decompilation and automatic ‘Step Into'(F11) code without source a reality.
To help, we came up with the ‘ROB’. For the world outside it’s known as the ‘Reflector Object Browser’. You can now right click on any assembly in the ‘ROB’ to make it debuggable. This generates the .pdb file for that assembly in the cache directory, and enables you to dynamically step into the implementation of an assembly by just hitting F11. Similarly, you can also double-click on any method in the ‘ROB’ to dynamically generate the code for it in Visual Studio.
So, why this new early access build just within a week of the previous early access build? Well, we decided that this sprint would be all about doing some housekeeping tasks which we’ve wanted to do for a long time, but didn’t manage to prioritize earlier. We’ve now managed to fix quite a few bugs around general usability, ‘Go to Definition’ functionality, licensing, and SmartAssembly.
Here is an entire list of what’s new for this EAP:
‘Go to Decompiled Definition’
We re-introduced the ‘Go to Decompiled Definition’ right-click menu item in the Visual Studio text editor. It enables you to go to the definition of a type decompiled by Reflector, if there is a conflict with the Visual Studio ‘Go to Definition’ behaviour. For example, right-click on ITypeDescriptorContext, and click ‘Go To Decompiled Definition’:
The Go to Decompiled Definition menu item
This takes you to:
Viewing the decompiled code.
Issues with different versions of the same assembly
There were problems with dynamic code generation for two versions of an assembly being shown in the ‘Reflector Object Browser’. For example, if you have two different versions of mscorlib, you should now be able to inspect the code for each version simultaneously.
Better ‘Go to Definition’ support
‘Go to Definition'(F12) should now work for many more keywords which weren’t enabled previously, for example the ‘this’ keyword.
We fixed the long-lingering bug with the flatten namespaces dialog box. It seemed to appear regardless of whether the flatten namespaces option was turned on, and this is now fixed.
We managed to pull out a list of usability issues from our long-standing pool. We’ve looked at: Activation/Deactivation menu items, inclusion of icons in various places, some messages in the ‘ROB’, and sorting on the ‘Choose Assemblies to Debug’ dialog box (now enabled by version type and Isdecompiled check box in). We also have a modal dialog to let a user know that their methods are being decompiled whenever a request for dynamic decompilation is made.
Last but not the least, we’ve been able to fix few SmartAssembly issues sent in by those of you who tried our previous EA builds. Most of these were around licensing and installation.
As always we’d love to here your feedback on the latest EAP or anything to do with .NET Reflector so please drop us a line on the forums or the EAP pages.
The work on getting Reflector working inside Visual Studio is progressing fairly quickly. In the previous EAP, we detoured a little, re-implementing the existing Addin as package (for users of VS2010 onwards) in order to allow us to get tighter integration into Visual Studio.
This has allowed us to work with the F12 shortcut and associated “Go To Definition” command, dynamically decompiling source as needed.
As in previous EAPs, the Reflector Object Browser (ROB) is populated with the assemblies that are referenced by your solution. You can then navigate through these assemblies using the Reflector tree, double-clicking at any time to decompile and display the source in an editor window. For example, here I navigated to AppDomain in the ROB and double-clicked…
Acting on some conversations we’ve had with the guys at Microsoft, we’re currently in the process of changing how we integrate with Visual Studio. Specifically, we’re moving away from being a Visual Studio add-in, and towards being a Visual Studio package.
I’ll keep this brief, because there are only really a handful of points which are interesting, and we’d love to get some feedback on the latest work. The main thing is that the VS addin now tracks the loaded project(s) references, and shows them in the ROB. Adding a reference (see below) adds that assembly to the ROB.
By now, you should have heard about our Early Access Programme. Now that we’re releasing rapid and regular early access builds, it’s time we gave you a better feedback channel. As a first step, we’ve created a UserVoice forum dedicated to EAP feedback, and we’d really appreciate hearing anything you’ve got to say about the new builds and new features. We’ll also use it to let you know when we’re working on your suggestions, and keep you up-to-date on our plans.