Carlos Quintero (MVP, and developer of MZ-Tools) recently wrote a blog post on debugging into Visual Studio’s assemblies. We liked it, and asked him to tell us a bit more…
Using .NET Reflector to understand and debug Visual Studio assemblies
As a developer of Visual Studio add-ins, I have been using .NET Reflector to understand the internals of Visual Studio assemblies since many years ago, and I consider it an invaluable tool for developers of Visual Studio extensions (add-ins, packages, etc.). In this guest post I will explain why.
Developing a somewhat complex Visual Studio extension, there are two scenarios where you may desire to have the Visual Studio source code and even to debug its assemblies:
- To understand how Visual Studio does some kind of things, because you need to do the same or similar ones in your own extension.
- To guess which code path inside a method is actually used at run-time. I mean: you may have the source code of a Visual Studio assembly with some complex logic, and it is difficult to guess which branches are actually executed for certain cases.
Microsoft has released the source code of the .NET Framework and you can even debug its assemblies, but it hasn't done the same with Visual Studio assemblies. This is where. NET Reflector comes to the rescue. You can use .NET Reflector for those two scenarios. I’ll illustrate this with a real case…
If you’ve tried the .NET Reflector 7.7 release, you’ll notice some new commands have appeared across the program. These are the remains of the Power Commands we integrated into the tool a while back, and as part of my work on add-ins I’ve moved the most useful ones into the foreground to make them more accessible and easier to use. These commands could previously be enabled from the options menu, but they hadn’t been worked on in a long time and had run into disrepair; some were confusing and others downright broken.
Here’s a rundown of the updated commands and how to access them from within Reflector.
This is a guest post from Wesley Steiner, the author of .NET SmokeTest, explaining his app, and how it works with Reflector.
What is .NET SmokeTest?
.net SmokeTest is a Windows application that presents an interactive interface into any .net Assembly allowing you to smoke-test an API via reflection. You can call any member without ever writing a single line code. An indispensible tool for anyone involved in developing, testing and managing software products for Windows.
Anyone remember Deblector? It was an add-in for Reflector 6 which provided debugging support. It became open source in 2007, but ceased development at Reflector 6.5 a few years ago.
In the last few weeks I’ve picked it back up, in order to investigate whether debugging could make it into the next version of Reflector Desktop as a novel feature. This is a request we’ve had a few times over email and in the forums, when users either can’t start up Visual Studio (or prefer not to), but still want to be able to easily pinpoint bugs in their code.
As a working prototype, Deblector was a superb starting point for this investigation.
Visual Studio 2012 is slated to ship soon, and when it does, Reflector will be sim-shipping right there alongside it. As part of our work to support the newest technologies from Microsoft (C# 5, WinRT, .NET 4.5) we’ve been working on Visual Studio 2012 integration and the new theming styles.
Nigel, our developer who’s been doing most of this UI coding, tells us a bit more about the work involved and how he did it:
A long, long time ago in a galaxy far, far away, Sean Hederman wrote an add-in for Reflector called Reflector.Diff. It was originally created to help him dive into code differences between Framework versions, but he figured it could also work nicely for people who wanted to diff their own assemblies.
We got in touch with Sean, and he gave us some more details into how he developed the Algorithm and UI in Reflector.Diff 2
Hopefully you’ve had a chance to check out the many add-ins available to extend .NET Reflector’s core decompilation functionality, as well as the suite of tools that use Reflector to extend their own capabilities. Silverlight Spy is one such tool with such an extensive set of functionality that it’s likely there things about it that you’ve missed.
If you’ve not used it yet, Silverlight Spy is a runtime inspector tool providing unprecedented access to all aspects of any Silverlight and Windows Phone application. It allows you to explore the UI element tree, monitor events, extract XAML, interactively execute DLR code, view statistics and much, much more.
Just before Christmas, I had an opportunity to talk to the inestimable Peli de Halleux, Microsoft researcher &, with support from Lutz, a prolific author of .NET Reflector addins. If you’ve not had the opportunity to read his blog, you should – he doesn’t post often, but when he does, it’s worth a look.
I’m very pleased to announce that many of Peli’s classic add-ins are now available from our .NET Reflector add-in showcase in one handy, productivity bundle.
(or “How to Check if Production Code is Obfuscated“. Another Guest post by David Connell (with a little help from Dom Smith, Jason Crease, Clive Tong, and Chris Massey)
David Connell, back again, and still a software developer at Red Gate. Here at Red Gate we are careful to obfuscate released software in order to help protect our intellectual property, and the obfuscation is performed by one of our other products, SmartAssembly, which should be run by our build system automatically. If you recall, I’ve been looking at a way to use .NET Reflector to automatically check whether our products are obfuscated, and I’ve made the full source code for the solution available at the bottom of this post.
The trouble with having a code base that you didn’t write yourself is that you’re often surprised to discover features that you’ve never seen before. I had this revelation some time ago when I was looking through the Reflector code, and had a close look at the IAssemblyManager interface: