Tuesday, July 19, 2011 10:57 PM
It's been sometime since I worked on this project. Everything still seems to build just fine, but when trying to trying to set breakpoints in my actual Silverlight app (a composite of 5 projects), I can't; when debugging they become hollow with a warning icon and a hoverover stating the "Breakpoint will not currently be hit. No symbols loaded for this document". However I can set brakepoints on the server-side code and they remain active. This seems different than most writeups I seen which can't set breakpoints.
Looking at the modules window, it shows that the PDBs for the actual Silverlight client are not being loaded although many others are. I can't manually load them because of a match issue; however thay are being built and deployed to the \bin\debug, \obj\debug and appname\bin folders (Is this not were I should be looking?).
Based on my research, I have applied the IIS localhost fix for IE9, emptied the IE file cache, deleted the \debug folders and the \bin folder, emptied the symbols cache in VS2010 and manually added the various paths to the PDB files of the 5 projects. I haven't emptied the GAC yet. Headed in that direction now.
Any other suggestions?
Wednesday, July 20, 2011 3:34 AM
Hi Marc. Most of the time the reason for this problem is that Visual Studio is not attached to the correct browser process. You can check that by looking at "Debug/Attach to Process...". Search for the browser process that has the type "Silverlight" listed and if necessary attach Visual Studio manually to that process.
If this is the reason for your problem, you can automate this by using my Silverlight Debug Helper tool.
Wednesday, July 20, 2011 7:33 AM
Thanks for replying. Looking at the processes available, the "Silverlight" IE process is greyed out which I assume indicates it is the one currenly attached to. Looking at the modules, my 5 modules are associated to the same process id as the former greyed out process. There are numerous other modules also associated with that process; some loaded, some not. There is only one other process present in the list, that of the WebDev.WebServer40.EXE: Managed (v4.0.30319) which makes sense.
It seems that if the path of the modules is "C:\Users\Marc.THOUGHTS\AppData\Local\Temp\Temporary ASP.NET Files\root\..." that the chances of the module not loading is high. One thing I noticed is that none of my modules show a physical path, instead just their names are listed. That doesn't seem right.
Wednesday, July 20, 2011 8:50 AM
Hm, that really seems odd. You've done all the steps I would've recommended next already, like cleaning/rebuilding the solution, manually removing bin/obj folders, making sure that the browser cache is not interfering etc.
One thing I've once ran into with a project I was working on was that someone had changed the source path of the Silverlight XAP file (in the HTML page) and let it point to a different location, not the one where Visual Studio deploys the Silverlight application to (e.g. the source location points to "SilverlightApps/MyApp.xap", but Visual Studio compiles to "ClientBin/MyApp.xap"). Then of course debugging also never works because the loaded XAP is an old version that doesn't match the source code. Did you check something like that too?
Wednesday, July 20, 2011 2:58 PM
Actually I had just resolved it and came back to say the same thing: the default.asp had the Silverlight.xap set to run from the publishing point not from my workstation. Good shot at the dark!!! I had forgotten that I had changed it.
Wednesday, October 19, 2011 5:46 PM
Hi Peter and Marc!
I am just getting to this thread now, after Googling "Breakpoint will not currently be hit" for weeks on end. I'm tired of debugging by trying to sort through the wreckage to see whether it's the fuel pump or the alternator that's the problem. :)
So first of all - thank you thank you to the community here that is so helpful!
I too have tried all the 'usual' fixes, and the issue seems to be VS (2010 Premium)'s inability to attach correctly. I can do it manually, but alas, Peter's Debug Helper tool is not running in my cockamamie environment (Win 7 32-bit inside Parallels on a MacBook Pro). I'm guessing that that's the end of the road for me, unless there's a better solution.
My gosh, but it seems like MS should fix the attach issue, already, shouldn't they? From my Googling, it looks like this has been around for years!
Anyway, thanks again to the community, and if there are any updated pointers, I would love a hand!
Wednesday, October 19, 2011 11:48 PM
Hi Aaron, I've replied to the email you sent me.