silentC

I have been 'developing' with Visual Studio 2005 for about 3 weeks now - primarily .NET class libraries developed with VB. I am coming from VB6, although I did a lot of development with Visual C++ several years ago, so I am still trying to come to terms with the debugger.

I have read many threads posted by people who are having a problem with breakpoints, specifically with the message in the subject line above. There have been many suggestions on how to fix this problem. Sometimes these suggestions work, sometimes they do not. Most of the suggestions involve deleting DLL and PDB files and rebuilding, or restarting Visual Studio. None of them suggest any problem with something the developer has done or any problem with the configuration of the development machine.

To me, the inability to reproduce the behaviour at will, and the fact that the'work arounds' work some of the time but not all, indicates to me that this is a bug. People have denied it but to my mind the evidence is there.

For example, just now I have had this problem. I deleted all files from the Debug directory, rebuilt the project, rebuilt the TLB and re-installed in the GAC. No good, the breakpoint still shows the 'will not be hit' message. Totally frustrated, I decided to try running the client anyway, which I did. Naturally it did not stop at the breakpoint. I shut down the debugger, started it again (attaching to a process) and lo and behold, the breakpoint is now working. So what did I do to make it start working If starting and stopping the debugger fixes the problem, how can it be anything I have done wrong or failed to do

This problem is very frustrating and it has made my current development task take much longer than expected. Something as simple as step through debugging should be a given in a development tool like this, as it is in VB6.

What I would very much like is for someone who knows to explain what I am doing wrong, if such is the case, or explain how this is not a bug. If it is a bug, then I would like to hear from someone at MS regarding whether or not it is being looked at, and if so, when we can expect a service pack. This issue is costing people time and money and I know I'm not the only one experiencing this problem. Alternatively, if someone can tell me that I am doing something wrong, tell me what I should be doing, and I can move on to what I am supposed to be doing, I would be very grateful .


Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

rchiodo - MSFT

This might be a case of your class library being gac'd, then a rebuild occurs. The application will load the old gac'd assembly which the debugger will see as not matching your local PDB file.

The solution is to ungac your old assembly (gacutil -u <assembly name>) and then regac your newly built assembly. You'd have to do this after every build.

Another solution is not gac your assemblies while debugging, although that might not be possible based on how your application is loading them.





Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

rchiodo - MSFT

Sorry, I thought of some more info.

Using the modules window you can also check to see what version of your dll is loaded into your application.

If the version showing up in the modules window doesn't match the PDB that would explain why it can't load.

The version number you want to see in the modules window should match the DLL you just built. You should be able to check the DLL just built using windows explorer.

I'm going to add a suggestion for VisualStudio that we do a better job of pointing out why a PDB doesn't load. I know the GAC problem (if that's what your issue is) is a very common problem.





Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

silentC

Thanks for the reply. I have been re-installing the dll in the GAC after each compile and that seems to deal with the issue partly. I'm calling from VB6 and I've found that if I attach to the VB6.exe process, make a call from the VB client code, stop the .NET debugger, reattach to the VB6.exe process, then my breakpoints work. I don't understand how or why that works but it does seem to be repeatable.

I guess where I am coming from is that the whole debugging process is now way more complicated than it was under VB6. For me, this is a fairly serious time waster. However, I'm prepared to try and understand it better and maybe I can get on with it.

Thanks for the tips, I'll try them out.




Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

Shrikant Bijapurkar

I am developing a Addin in VB.NET using VS 2005 IDE.

I have started getting the same problem "Breakpoint will not currently be hit. No symbols loaded for this document." since yesterday.

Till this point in time, nothing seems to help me.

Has there been any latest updates on this from MS





Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

Davant

Deleting files in the c:\windows\microsoft.net\framework\v2¡­\Temporary ASP.NET File\ProjectName\...\...

Worked for me.





Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

LurkingVariable

I've been fighting this issue all day. I have a VB.Net 2005 solution that contains a DLL and an EXE (a test harness for the DLL). Based on other suggestions I've seen, here are the steps I've taken to resolve, none of which have solved my issue:

-Solution Properties --> Config Manager --> Active Solution Configuration set to Debug
-Check that the timestamp on pdb and dll file are in sync
-Delete the entire shadow copy cache at c:\documents and settings\<user name>\local settings\application data\assembly.
-delete bin and obj folders, restarted, and tried again
-remove the strong name signing
-Delete all instances of *.pdb files in project directories
-Uninstall assembly from GAC
-If you have project files that are in different directories but share the same name, give them different names.
-Ensure that DLL's and PDB's are not under source control.

I can't believe how much time I've wasted on this. ALL I WANT TO DO IS HIT A BREAKPOINT!





Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

SpindletopX

I've got the same problem using VC2005, either strange. Output message:

'project.exe': Loaded 'Z:\M', No symbols loaded.

I do not know why the Path is called "M" (this is only the first character of the full pathname). Ok, I will ignore that, "Z:" is a VMWare network drive (\\.host\Shared Folders\My Projects) and I could not get the program debugged. But storing/compiling the project from the local drive or a "real" network drive, the debugger is working. Reason could be that tha path \\.host\Shared Folders\ is not accessable, but the subfolders are. The debugger may have a problem with this, the executable and all other programs run this way...





Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

Duncan Faulkner

Hi Guys

Is there an update on this subject I have an 8 project solution (of which one is a web service) that used to let me debug any of the applications, just by setting a breakpoint. Now all I can set is breakpoints in the main application and the business logic level, any break points set in the dataaccess layer (which is called via the web service) is not available (ie breakpoints will not be hit), this is so frustrating. I have cleared out all pdb files and rebulit all assemblies (none of which are installed into the gac), refreshed all pdb files in IIS and I'm still not able to get a break point to work. There must be a procedure for setting this and loading the pdb files, just not sure what else I need to do, can someone please help.

Thanks in advance

Duncan





Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

LurkingVariable

I wish. I'm still dealing with this. All this expensive software and I'm reduced to debugging via message boxes!





Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

Graham T. Wade

I found a solution for this in VS2005 that worked for me (seems to be the case with most solutions for this) so here goes.

Bring up the project properties window then go to the 'Compile' tab. Under the Advanced Compilation Options screen select 'Full' in the 'Generate debug info' combo.

I had exactly the problem that is listed here and this solved it instantly. If it doesn't work then try clearing out the files in your 'debug' directory and you compilation directory and try again.

This solution obviously doesn't work for ASP.NET pages but I'm working on a solution for that and will post when I come up with one.

Good luck!!!






Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

Martin1307

Anyone found a full solution for this yet

I am in VS2005 using VB. I have hit this problem out of the blue on code that I used to be able to debug as I wished. I found the 'FULL' option in the 'Generate Debug Info', but even that no longer helps.

I have no wish to become a guru on the internals of VS .pdb .gac ., nor do I wish to manually edit or delete 72.435% of my BIN directory after every compilation run.

Will SOMEONE at MICROSOFT PLEASE improve the CLEAN code to fix this rubbish, or fix it once and for all at source.

yours dejectedly

Martin1307






Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

Duncan Faulkner

Guys

Just to update on my issue, the reason I couldn't get the asp web service to debug was that IIS had reverted back to .Net framework 2.0 instead of 1.1 and as soon as I changed it back I was able to debug again, not sure why it changed but not the first place I would have thought to look at.

I agree with Martin and this should be more user friendly if nothing else, at least give an indication as to why the break point won't be hit and what needs to be done to correct it, afterall if VS knows that the break point can't be hit then there must be a condition it's checking for to come to that decision.

Duncan





Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

John Cunningham - MSFT

Actually, we are doing our best to indicate the issue of why the debugger is not breaking. To set a breakpoint in the running code, the debugger looks at all of the symbolic information it has loaded for every module and tries to find a match for your file and line number in that set. When it can't find any, that's the best it can do. So that's the condition. We are taking a look to see if we can improve the issue of incorrect framework selected, but it is difficult for us to understand user intentions sometimes (i.e. did you actually mean for the framework to be 2.0 rather than 1.1.). We could prompt a lot, but that may get distracting.

We feel your pain and are trying to figure out ways to mitigate it,

John






Re: Visual Studio Debugger Breakpoint will not currently be hit. No symbols loaded for this document.

Duncan Faulkner

Hi John

That would explain why there is no information on why it can't hit the breakpoint, I was not fully aware of how VS worked out how to hit a break point or not.

I can understand your pain and I'm sure you'll find away to overcome this eventually, but it can be rather frustrating especially when a project did break on a break point and then (what seems to be) for no apparent reason not hit the break point, in my case the project was a 1.1 framework windows app with a webservice not quite sure why IIS changed over to version 2.0, unless another application had changed it, would it not be possible (at least) where IIS is concerned to check the application for the version of the framework, and set the IIS application to default to the correct framework based on the application, I know that that is a very simplistic view of it and I'm sure it wouldn't be that easy.

Well I hope you guys can find a solution to this age old issue, I for one would not be too put off having a dialog box pop up when then was an issue as long as it explained the fault and gave an indication as to how best correct it or at least a link to a webpage that provided more information.

Duncan