Options
.NET Reflector problems in VS2013
Bitterman
Posts: 7
I previously had .NET Reflector 7 working fine with VS2010 on my old PC. Now that I've bought a new PC, I am trying to get .NET Reflector 8 working with VS2013 but it's having some trouble.
1. When I initially went to Generate PDBs, it gave me an error about a NullReferenceException and seemed to do nothing. I can press the button to generate the PDBs again, and no longer get that exception error; but the PDB cache appears not to grow above 2MB, even with dozens of assemblies selected. It's not clear if this is actually a problem or not.
2. "Goto Definition" (F12) only inconsistently shows the decompiled source (other times it shows the same metadata as VS would if Reflector was not installed), and never contains any XML comment documentation (which the standard metadata in VS does!).
3. When I double-click external code in the Call Stack, it opens up both the decompiled source for that code, but also the Disassembly window. The debugger "thinks" it's in the disassembly, so even though the decompiled source is shown, I can't see where the current statement is, neither can I step through it. Most of the time, although the decompiled source shows the method I double-clicked on somewhere in the window, sometimes it can be several pages away.
4. If the current location while debugging is in async/await code, I get a callstack that contains none of my code at all (I know for sure this works without Reflector), and attempting to show any external code shows the disassembly only.
Basically debugging external code is completely unworkable, and Go To Definition is flaky and unreliable. This is not what I paid money for. Please advise how I can resolve these issues.
This is using a registered version of .NET Reflector 8.4.0.1, VS2013 version 12.0.30723.0 Update 3, and JetBrains ReSharper 8.2.2000.5102.
1. When I initially went to Generate PDBs, it gave me an error about a NullReferenceException and seemed to do nothing. I can press the button to generate the PDBs again, and no longer get that exception error; but the PDB cache appears not to grow above 2MB, even with dozens of assemblies selected. It's not clear if this is actually a problem or not.
2. "Goto Definition" (F12) only inconsistently shows the decompiled source (other times it shows the same metadata as VS would if Reflector was not installed), and never contains any XML comment documentation (which the standard metadata in VS does!).
3. When I double-click external code in the Call Stack, it opens up both the decompiled source for that code, but also the Disassembly window. The debugger "thinks" it's in the disassembly, so even though the decompiled source is shown, I can't see where the current statement is, neither can I step through it. Most of the time, although the decompiled source shows the method I double-clicked on somewhere in the window, sometimes it can be several pages away.
4. If the current location while debugging is in async/await code, I get a callstack that contains none of my code at all (I know for sure this works without Reflector), and attempting to show any external code shows the disassembly only.
Basically debugging external code is completely unworkable, and Go To Definition is flaky and unreliable. This is not what I paid money for. Please advise how I can resolve these issues.
This is using a registered version of .NET Reflector 8.4.0.1, VS2013 version 12.0.30723.0 Update 3, and JetBrains ReSharper 8.2.2000.5102.
Comments
Hello?
So very sorry for the delay! I'm not sure why a ticket did not get logged for this forum post. Usually, the best way to contact us is to email us at support@red-gate.com to directly log a ticket.
Is there an option to send in an error report when this error occurs? If so, can you kindly send one in and enter your email as bitterman@forums.com so that we can find it and check the stack trace leading up to the error?
Can I also please check, if you manually go to the cache in %userprofile%AppDataLocalRed Gate.NET Reflector 8Cache, do you see all the pdbs for the assemblies you've selected?
Can you kindly double check that the .NET Reflector> Go to Deifnition (F12) menu option is checked? If it's not, that could explain the issue. F12 would take you to decompiled code if you were using it on code created by Reflector (opened from the Reflector Object Browser -- it should say "Generated by Reflector.." at the top), but would open metadata from your own code when used on types you don't have source for.
If it is already enabled though, can you please take note of any patterns for when one or the other happens? Do you only get metadata when you use F12 on particular types? Maybe from a certain DLL?
Can I please check a few things:
-Is debugging already enabled on the assembly containing the code?
-If you go to Debug>Windows>Modules while debugging, is there a pdb file loaded? If so, is it the one created by .NET Reflector?
I'll have to reproduce this--please bear with me!
Jessica Ramos | Product Support Engineer | Redgate Software
Have you visited our Help Center?
Jessica Ramos | Product Support Engineer | Redgate Software
Have you visited our Help Center?
I set it to "Generate PDBs" again and started typing an update in this browser window... while I was typing, an error dialog appeared and took focus, and just as I pressed the space bar, it interpreted that as a button press and closed Visual Studio! (Didn't see if it was an error from Reflector or VS itself).
So I went back to do it for a third time, and this time it showed the cache as considerably larger than 2 MB (now 727 MB)... it seems the second attempt had at least partially succeeded before the error occurred. I checked the location you mention, and there are now lots of PDBs (and some decompiled CS files) there. Anyway, as there were still a few that hadn't been cached, I set it to generate the cache again, and it crashed again, so I sent the error report to the address you mention. Hope it helps.
In summary, "Generate PDBs" now seems to have at least partially succeeded, whereas at the first attempt it failed completely. As a result, I'm now getting much better results for the other problems: I am now getting Reflector decompiled code whenever I use F12, debugging external code is working properly, and debugging async/await code is working properly. It seems that the initial failure to Generate PDBs caused all of those problems, and I'm much happier now. That just leaves a couple of concerns:
- Is the initial failure to Generate PDBs likely to cause longer-term problems? (eg. if I need to generate more, for other DLLs, later?) Hopefully the error report should help determine this, it may be that it's fine from now on.
- Couldn't Reflector be a bit "smarter" / more reactive in terms of when to Generate PDBs? ie. if I haven't already generated a particular PDB, I'd hope it would do it "just in time" when I attempt to debug into it... it may not always be clear which assemblies will need to be debugged, until it's time to debug them. If that had been the case, I might never have noticed a problem. Am I expecting too much?
- The code generated by Reflector's F12 still does not contain any comments from XML documentation. Picking an example from the first page of code I'm looking at: pressing F12 on string.Replace(...) takes me to the Reflector decompiled code for that method in mscorlib.dll, including an attribute, but with no comments. However, leaving the cursor on string.Replace(...) and viewing the Visual Studio Code Definition Window shows me the method signature (no code of course), but also the comments from XML (Summary, Parameters, Returns, etc). When the XML documentation is available, it should surely be used by Reflector?
Many thanks for your help.
- Is the initial failure to Generate PDBs likely to cause longer-term problems? (eg. if I need to generate more, for other DLLs, later?) Hopefully the error report should help determine this, it may be that it's fine from now on.
The report was linked to the issue we have logged internally as RP-3368, though we unfortunately don't know much about this yet. I've actually been able to reproduce it myself before and found that it happens quite sporadically when generating pdb files for certain DLLs, though the pdb files usually are created successfully despite the error. If the pdbs aren't getting created in the future, please let us know!
- Couldn't Reflector be a bit "smarter" / more reactive in terms of when to Generate PDBs? ie. if I haven't already generated a particular PDB, I'd hope it would do it "just in time" when I attempt to debug into it... it may not always be clear which assemblies will need to be debugged, until it's time to debug them. If that had been the case, I might never have noticed a problem. Am I expecting too much?
That's definitely not expecting too much and I've gone ahead and created a feature request for Reflector to be more intuitive and automatically enable generate pdb files for code that you've set breakpoints on (RP-3710).
- The code generated by Reflector's F12 still does not contain any comments from XML documentation. Picking an example from the first page of code I'm looking at: pressing F12 on string.Replace(...) takes me to the Reflector decompiled code for that method in mscorlib.dll, including an attribute, but with no comments. However, leaving the cursor on string.Replace(...) and viewing the Visual Studio Code Definition Window shows me the method signature (no code of course), but also the comments from XML (Summary, Parameters, Returns, etc). When the XML documentation is available, it should surely be used by Reflector?
Very sorry to say the XML documentation is not available from the VS extension-decompiled source files (you can see the comments from the Reflector desktop application though when the file is available) . I've also added a feature request for this (RP-3711).
Apologies for the troubles you ran into and the lacking features! Please let us know if you have any further questions.
Jessica Ramos | Product Support Engineer | Redgate Software
Have you visited our Help Center?