Debugging when in the GAC is usually pretty frustrating. The biggest frustration is the time it takes to do an IISRESET and sit and wait for the web page to come back up after it rebuilds the cache. This can easily take a minute or 2, and if you're making frequent updates, you could spend half your day twiddling your thumbs. So in that sense, the best tip of all would be to do your development in the BIN of the web application (C:\inetpub\wwwroot\...), rather than in the GAC!
However, for things like workflows or event receivers, you CAN NOT be in the BIN and you're stuck dealing with the GAC and the slowness that comes with it. Although the following is a simple tip, I bet it is not commonly known.
When you get an exception in .NET while in the GAC, you'll often get a neat stack trace such as the following:
While this stack trace can be helpful in identifying which class and method threw the exception, it won't tell you which line of code broke. However, when you stick the PDB file in the GAC along side the DLL, the stack trace will show the actual line of code that broke! Also, this can be helpful if for some reason you can't get remote debugging to work.
To get the PDB in the GAC, navigate to start, run and type c:\windows\assembly\gac. Then, click the "assembly" in the breadcrumb, and then open the GAC_MSIL folder. Lastly, open the folder with your DLL name and drag and drop the .pdb along side the DLL. After you restart IIS you'll start getting traces that look like the above image.
[Note - this post isn't written to discourage proper exception handling! Take it as an FYI only :) ]
Phil Wicklund