5 Answers
5

F5 debugging is pretty cool, but for small and not complicated projects. You know, that by pressing F5 your solution will be deployed again, including all steps - add solution, install solution, activate features. And it often takes really long time.

There is a couple of extensions for visual studio that makes your life easier. As for me, I use CKS DEV extensions. How cks dev can increase debugging and even overall development process:

it has quick deploy actions - copy to gac\bin, copy to sharepoint root, recycle app pool, iisreset and so on

and also it adds new sharepoint project items (SPI) available in add new item window

Example how I use cks dev. To debug code, I've created new deployment configuration with this steps:
1.Copy to gac\bin
2.Recycle app pools
3.Warm up sharepoint site
4. Attach to IIS worker process.
Now every time I click deploy, I have updated dll in the gac, visual studio attached to w3wp and ready to debug. This of course works faster than full redeploy cycle. If I need only update files in 14 hive I use copy to sharepoint root command form context menu.

I am not pretty sure how you are debugging your SharePoint portals right now. But I would suggest you look at the Visual Studio 2010 extensions and different techniques that make debugging life easier. Please go through this post where all these are consolidated at one go.

When the piece you are debugging can run from a sandboxed solution, F5 debugging is much faster. For one thing, you don't have to recycle the application pool. To me, that feels much more like the typical plain asp.net debugging situation.

Not every solution can fit in the sandbox and benefit from this speed up. Sometimes, the incompatability with the sandbox may be a small piece that you can extract and remove temporarily. If you're doing a lot of debugging, it may be worth it to extract the piece you're working on the most to run it in the sandbox during development.

I also suggest looking at the Microsoft Patterns and Practice groups documentation and code samples for logging. Logging can be a big help when debugging is slow, like for GAC assemblies that require app pool recycles on low resourced dev machines.

one quick tip:
after recycling the application pool of the project. in the attach to process window you can sort desc process by name and choose the first w3wp.exe to attach and no need to select all of them.
in 90 percent of times it work just fine.

Stick an automatically generated version number into your AssemblyFileVersion - and make sure you can see it somewhere, even if it's just an HTML comment in the page source. And use the AssemblyFileVersion, 'cos then the strong name is unchanged.

Ctrl-Alt-E brings up the exceptions dialog, where you can configure what ones are trapped. I like Visual Studio to break on handled exceptions, as well as unhandled ones.