If you are developing components, features, Web Parts and other things for SharePoint, MOSS or WSS you all know that when you have to start debugging some nasty things can happen. One of those things is that the debugger tells you it isn't connected to any process. It gives you the message "The breakpoint will not currently be hit. No symbols have been loaded for this document" at the breakpoint in your code.
So how does debugging with SharePoint solutions work? Developing solutions is done in Visual Studio and in most cases a Control Library. When compiling this library you will get an assembly which you install in the bin folder or the GAC. Secondly you start the SharePoint web application to which the solution is deployed or installed. Then you connect to the process of that browser (w3wp.exe) instance running the web application and there you go.
But as i said sometimes it just doesn't connect. I have done a lot of development with SharePoint and always use the following check list to find out what the problem is:
-
Did the solution really compile? I see sometimes developers causing a large amount of warnings causing not to see if there were any errors present. Then they copy the old assemblies to the bin folder or install them to the GAC causing this problem.
-
Are you connecting to the right w3wp.exe process? Is it not a non-closed browser instance?
-
Use IISRESET or better Recycle the Application Pool of your Web Application
- Check if the compiled assemblies are the same one placed in the bin folder or the GAC. Even if there is nothing changed between compiled versions of assemblies it could cause problems with debugging.
-
It could be that the instance of the browser is using a cached assembly version. As you know when starting ASP.NET applications it caches the runtime versions of the assemblies. Clear the .NET Framework temporarily internet folder and subfolders. This folder is:
"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files". If you are not able to clear this make sure that you did an IISRESET, closed all browser instances and closed Visual Studio.
-
If you are developing by putting the assembly into the bin folder, make sure that the instance of the browser is not using a GAC deployed version of the solution. I have seen this happening with collegaes which by accident used the wrong batch file for deployment on their development machine. The GAC version was accessed instead of the assembly in the bin folder.
-
Finally if you are working in a VPC or VMWare environment it could be that by using the debugger too often the whole environment is messed up. In that case do a restart of the environment and walk through the all the above points again