Tuesday, December 2, 2014

Let's "dotStep" into their code


I've used dotPeek for a while to look at source code of third party decompiled assemblies but this time I decided to experiment with actually stepping into their code. There are numerous resources out there, such as

https://confluence.jetbrains.com/display/NETCOM/dotPeek+Symbol+Server+and+PDB+Generation
http://msdn.microsoft.com/en-us/library/ms241613.aspx

and many others. Setting up Visual Studio options is straightforward until you feel you know enough to change things a bit. That's what I did and that's what caused me some trouble. BUT by going through that helped me understand the process better.



In the above diagram there are two paths: one for symbols cache directory in Visual Studio Tools > Options > Debug and the other in dotPeek. They have to match. The other crucial moment is if you choose Automatically Load symbols for "only specified modules" you have to make sure you spell the dll's name correctly. In the example above it is the Sitecore kernel and it has to contain the extension (.dll).

Many blogs omit describing the step of actually setting a breakpoint in decompiled source code. You can see it in the above image (notes in blue). Debug > New Breakpoint > Break and function and then type in the method name with the namespace and class (for example: Sitecore.Security.Accounts.IsAuthenticated). And hit F5. The process takes a while even if you have only Specified assemblies checked in VS and same in dotPeek. Patience better be your main virtue...and vuala - you get your breakpoint hit! Congratulations! You can now verify that's it's not YOUR code that breaks everything. it's THEIRS, you know what I mean? ;) Enjoy!


1 comment:

  1. Cool guide. I took the information and your post and I did. I think you need to work in this direction. I would like to offer you this web site for downloading dll http://fix4dll.com/steam_api_dll file. If you love to play games, he will help you.

    ReplyDelete