The bane of every developer: Visual Studio doesn’t hit your breakpoints! It usually happens when creating extensions for a program and there are two general reasons for this:
- Visual Studio and the program to be extended load different versions of your extension
- Visual Studio 2010 uses the wrong debugger
I’ll use SharePoint and a .dll file as an example but you can substitute “SharePoint” with “program to extend” and “.dll” with your type of extension.
Visual Studio and the Program to be Extended Load Different Versions of Your Extension
Use Process Explorer (see External References section) to check from where Visual Studio (process devenv.exe) and SharePoint (one of the w3wp.exe processes or the OWSTIMER.EXE process) load your .dll file. Chances are that the locations don’t match.
One problem I found was that SharePoint loaded the correct version of the .dll file from the GAC (C:\Windows\assembly\GAC_MSIL\…) but Visual Studio loaded it from C:\Windows\assembly\temp\… which is used for uninstalling assemblies from the GAC. Re-started Visual Studio–problem solved. OWSTIMER.EXE loaded the .dll file from the wrong location, too. Killed the process (it will be re-started automatically)–problem solved.
SharePoint only: another nice twist comes from creating extensions that are used by Central Administraton and normal sites. Visual Studio will only recycle the application pool for normal sites leaving you with Central Administration using an outdated version of your .dll file. Check the timestamp in Visual Studio’s modules window and if it doesn’t match recycle Central Administration’s application pool or restart IIS.
Visual Studio 2010 Uses the Wrong Debugger
Visual Studio 2010 uses the wrong debugger–what??? Visual Studio 2010 is the first version that has two .NET debuggers at it’s disposal: one for .NET 4.0 and one for all previous versions of .NET. If you are debugging an extension Visual Studio may get it’s debugger choice wrong. A telltale sign of this scenario is an empty modules window when you are attached to the process in question. This issue will be fixed in SP1 for Visual Studio.
If you are developing for SharePoint you can use this workaround:
- If you are debugging detach from all processes.
- “Attach to Process” window: select the process you want to debug. It will probably list “Managed (v2.0…)” and “Managed (v4.0…)” as types.
- “Attach to Process” window: click “Select”. The “Select Code Type” window appears, probably with “Automatically determine the type of code to debug” selected.
- “Select Code Type” window: select “Debug these code types”, check “Managed (v2.0…)”, and click OK.
- “Attach to Process” window: click “Attach”. Your modules window shouldn’t be empty anymore and your breakpoints should work.
If it doesn’t work the first time try checking “Managed (v4.0…)”, attach (this should not work), detach, then attach again with “Managed (v2.0…)” checked.
I have also seen Process Explorer showing a process had loaded my .dll file and Visual Studio not listing it for this process. And of course the breakpoints didn’t show as solid dots but only as circles. But they worked once the respective statement was executed. So as long as the modules window isn’t empty you should be OK regarding this type of error.
Just remember to revert the setting back to “Automatically determine the type of code to debug” when you start working on a different type of program.
When working on extensions for other programms you can probably create a .config file specifying the debugger version to use. See the External References section for details.