You Don't Need to Copy PDB Files to Debug in the GAC!

eLumenotion Blog

Untitled 1

New Public SharePoint Classes in Atlanta!
November 17-19 and December 1-4

eLumenotion - SharePoint Training and Consulting > eLumenotion Blog > Posts > You Don't Need to Copy PDB Files to Debug in the GAC!

11/12/2007

You Don't Need to Copy PDB Files to Debug in the GAC!

Following up on my last post, many developers choose to put assemblies into bin because they find them easier to debug. Usually, they do not create detailed CAS policies. Instead they simply set the trust level to full so they can 'just make it work'. While this is a sentiment I can fully understand having wrestled with it myself, it's not the best idea. Generally, I think most will agree that the closer the development environment's configuration matches the production environment the better. So developing with assemblies in BIN with the web config set to full trust and then deploying them at the last minute to the GAC just makes me feel unclean.

Fortunately, it's just as easy to debug in the GAC as it is in BIN if you configure the development environment correctly. Unfortunately, few know how to do this because the internet is polluted with pages full of bad information that is a held over from previous versions of .Net. You can spot these easily because they will say you need to copy the debug symbols (.pdb file) to the GAC. In and of itself, that will not work. These days it is also completely unnecessary.

To configure VS 2005 to debug the assemblies properly, do the following:

Open Tools | Options.

Check Show all settings if needed and locate Enable Just My Code (Managed only)

Uncheck it and click OK

Attach to the w3wp.exe process for the instance you want to debug.

There may be more than one. You can attach to all of them, but only the first one will be debugged. To verify that you are attached to the correct instance of w3wp.exe, open the Modules window by pressing CTRL-ALT-U.

If your assembly is listed, you picked the right one. If not, choose stop and attach to the next one until you find it.

In this example, the assembly is loaded. Note that the symbol file is loaded and that it was not copied to the GAC.

My breakpoints are hit! Yay!

P.S. Don't forget the set debug="true" in the web.config or it won't matter where you put the assembly! This can really trip you up if you forget to do it because the breakpoints will turn all nice and red, but it won't stop.

Note: I renamed this post because I want people to read it and I decided that some might miss the message based on the earlier title.

Posted at 10:52 AM by Doug Ware | Category: Debugging | Permalink | Email this Post | Comments (9)

Comments

Symbol Caching and Search Folders

You can also configure a symbol server or search paths, and alter your build process to publish the PDB files out to the symbol server or cache directory. Then you can always have symbol information available, no matter what version of the assembly happens to be loaded (very useful for troubleshooting a production or QA environment problem where you otherwise might not have retained the pdb files). It's easily configured through the Symbols section under Debugging in the VS Options dialog.

This can also be very handy for team development scenarios where one developer is building assemblies that are used by others who do not necessarily have the proper PDB files available to them without a central repository.

Dan Attis at 11/16/2007 4:24 PM

Very True!

Lol! There goes my follow up post. :)
Just kidding. Those are great points Dan!

Doug Ware at 11/16/2007 8:13 PM

PingBack from http://drewmace.blogspot.com/2007/11/debugging-from-gac.html

Good article.

http://drewmace.blogspot.com at 11/21/2007 11:55 AM

Thanks!

This is a Godsend in SharePoint, where GAC deployment is generally the way to go. I'll have to come up with a good topic for follow-up with respect to feature/solution development, as supportability is a *HUGE* concern for my clients. http://www.thomascarpe.com/ Cheers!

Thomas Carpe at 12/11/2007 2:47 PM

Does it work for remote debugging?

Hi,
I tried your methods for debugging a remote MOSS server but when no symbol was loaded for the DLL i was trying to debug.

I tried to load the symbol by pointing to a PDB file on my local machine, but VS2005 keep saying the "The symbol file <assembly>.pdb does not match the module".

Only when i copied the PDB to the c:\windows\assembly on the remote server did i finally can get the symbol loaded.

How can I debug remotely without copying the PDB to GAC?

Thanks.

Anon at 5/14/2008 4:57 AM

Pingback from http://coderjones.blogspot.com/2008/08/debugging-moss-workflows.html

Thanks for this information! I have linked back and suggested anyone who reads my blog to check this out.

Jeremiah at 8/17/2008 9:34 PM

re: Does it work for remote debugging?

for remote debugging i manualy put the pdb files into "c:\windows\dll\"

pro:
- u don't need to now the full GAC Name with version number/pkey a.s.o.
- it workx :)

btw: to copy the dll remotly into the gac with "Post-Build Event", use remcom.exe -> http://talhatariq.wordpress.com/projects/remote-command-executor-xrce/

dataCore at 9/23/2008 11:31 AM

You, my friend, get a gold star!

I've been using www.codeplex.com/STSDev (great tool, BTW) and trying to get debugging to work with MOSS Web Parts. I've been chasing my tail in circles. I've tried everything that I've found and nothing worked until now.

I tried this and it worked right away!

You get a Gold Star! Actually, you get two Gold Stars!

Cheers!

Mark DiGiovanni at 9/24/2008 11:17 PM

Thanks!

Worked great. This was a big help.

Anon at 10/3/2008 2:50 PM

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title

Body *

Your Name *

Attachments