SharePoint: Debugging Assemblies in the GAC (part 2)

I wrote an article on debugging assemblies in the GAC some time ago, see Quicknote-Easy-way-to-debug-assemblies-in-the-GAC . There seems to be a lot of conflicting view about what is required out there on the web, and how the debugger works is not something that appears to be widely understood.

The other day, a colleague of mine was saying that visual studio always allowed him to debug gac’d assemblies. He had no problem with symbol files loading. It turned out that he was dropping assemblies to the gac either manually through the UI or through gacutil /i. In the past, I had always packaged assemblies into a wsp and then subsequently deployed the wsps through stsadm – which did not permit me to debug gac’d assemblies.

I came across a really interesting blog post the other day however, at It basically turns out that the visual studio debugger works by matching loaded assemblies to the user that created them (see visual studio tools->options->debugging->enable just my code). This meant that my colleague was always able to debug the gac, as he had manually copied the code in, as opposed to deploying the code through stsadm (which must therefor install it as the service account?). If you turn off this flag, you can debug assemblies deployed to the gac through stsadm without copying pdb files around, just by attaching to the relevant w3wp.

Edit: also use the module window in visual studio (ctrl+alt+u) to see what symbols are loaded. You can also right click to manually load symbols for and assembly

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>