
I could attach to a running process easy enough, but to actually see anything I needed to trigger an exception. Secondly, there is no clear way to open an arbitrary assembly when debugging without a solution file. For those I had to use JetBrain's dotPeek. First, it was unable to process the C++ CLI assemblies. I was able to self-diagnose the problem and get my test servers up and running in a fraction of the time. I tried Reflector's debugger support and was amazed at how well it worked. With the other team on the wrong side of the country, or even the world, communication delays can cost me a day or more. On multi-team projects the other consulting firms often send me precompiled assemblies without any source code. Having that kind of instrumentation inside a Visual Studio may seriously reduce the time spent diagnosing the problems in third-party libraries. Picture 4: Debugging precompiled assembly
#Dot net reflector free download code
When PDB file is created, users are ready to step through the code of the assembly, set breakpoints and use regular debugging techniques (Picture 4). But first it will try to locate a corresponding PDB file on a local machine and use it. To debug precompiled assemblies, users should right click an assembly in Solution Explorer and choose "Enable debugging". NET Reflector Visual Studio add-in does decompilation on-the-fly. NET Reflector Object Browser (Picture 2) goes deeper into precompiled assemblies and enables users to browse internal classes, methods and the code. The standard built-in Object browser shows only public methods and classes (Picture 1), while. NET Reflector’s Visual Studio integration ( in VS and VSPro editions) is what most people really should know about. NET Reflector can decompile the assembly on-the-fly in Visual Studio and then step through it as if debugging an assembly with a source code. Debugging precompiled assemblies without any source code and PDB files is not easy without proper instrumentation.
