[c#] The breakpoint will not currently be hit. No symbols have been loaded for this document in a Silverlight application

Ok, what I have:

Visual Studio 2010 RC, W7 x64, started a new project type of Silverlight application. Hosting the Silverlight application in a ASP.NET Web Application Project. Silverlight Version 3.0. Added a LinqToSQL Class, a WCF Service, a Winform Tester Application (Project in the Solution) and a few Classes (also as Projects in the Solution).

Yesterday, suddenly I got the 'The breakpoint will not currently be hit. No symbols have been loaded for this document.' message to appear in the IDE, but it only affects the Web Appliaction, I can debug the Silverlight and the Winform App.

What I tried / did to get rid of the message:

• Reset Visual Studio Settings
• removed all files in every \Temporary ASP.NET Files Folder (there is one for each 32bit/64bit and for Framework 2.0 and 4.0)
• tried to debug using Visual Studio Integrated Web server - normally I use IIS, in the project output of the solution I deleted every obj and bin folders in every project folder
• created a new solution and added all the projects to this new solution
• deleted the solution suo file
• created a new ASP.NET Web Application to test if it is a VS-installation issue => I can debug this new project/solution
• rebooted the machine several times
• repaired the vs.net installation
• did an IISReset
• removed the Web App from IIS
• used the Create Virtual Directory Button under Project Properties of the Web App to create a new Web App in IIS
• changed the Framework Version of every project from 3.5 to 4.0
• Opened the Solution on my second machine => same behavior
• crawled Microsoft Connect for bugs / similar issues
• SPENT 7 HOURS.

So, this happens the 2nd time in my life. last time I solved it by deleting Temporary ASP.NET Files Folder, but this time I need your help.

This error crops up every now and then for me and I can always trace it back to project settings for the assembly concerned. You dont have to "wait" until your code fails to respect a break point or until you set the break point, to know which assemblies have symbols loaded.

When you run a project in debug mode it will list in the Output window which assemblies have symbols loaded as below (You may need to open the image in a new tab): T

So in this case BASD.Core.Data.dll does NOT have symbols loaded. So you can then compare the project settings for this assembly to that of another assembly that did manage to load symbols, in order to work out why some do and some don't load symbols.

"For me" however, "every" time this happens it's because the Debug info is not being created. So i open Project Properties > Build > Advanced in a (C#) project.

So for Basd.Core.Data.dll above i.e. no symbols the advanced build settings were:

Whereas for Basd.Core.Configuration.dll i.e. an assembly where I could set and hit a breakpoint the settings were:

So I'm outputting debug info in the latter project and not in the first, hence my ability to hit the break point in Basd.Core.Configuration.dll

Also note that it's not enough to simply have a .pdb file in the bin folder of a project for a given .dll because it might well be out of date and therefore not picked up by Visual Studio as a valid symbol file for the .dll you're trying to step through.

Also note that changing build configurations can change the build info settings and where symbols get pulled from.

(I realise in this case I'm in Release mode but the method still applies)

Debug - > Attach to process ->
choose Debug these code types: option ->
select Managed v3.5, v3.0, v2.0 or Managed v4.5, v4.0

Sometime right click breakpoint-->Location--> checking the allow the source code to be different from the original version works for me.

[EDIT]: Sometimes rebuilding entire solution also works.

This answer is not specifically related to Silverlight but the general error: The breakpoint will not currently be hit. No symbols have been loaded for this document. A noob mistake is that the project is not set as debug in configuration manager. Worth a check

I had this problem, but in my case it was because of a delayed loading of the module I was trying to debug. I had a DLL linked to my main project and the DLL is what I was debugging. The DLL was only called when certain functions in the main application were called so VS2010 didn't load the module until those functions were called.

When I started the project I recieved this message, but by the time I executed the function the debugger had loaded the module and the related debugging information.

This thread helped me a lot: http://geekswithblogs.net/dbutscher/archive/2007/06/26/113472.aspx

Please check the Web Properties of the web (Asp.Net) project hosting your silverlight xap. Go to Web project Hosting your silverlight xap -> Properties -> Web -> Debuggers Section -> Make sure that silverlight checkbox is checked.

I had a similar issue except my problem was silly - I had 2 instances of the built-in web server running under 2 different ports AND I had my project -> properties -> web -> "Start URL" pointing to a fixed port but the web app was not actually running under that port. So my browser was being redirected to the "Start URL" which referred to 1539 but the code/debug instance was running under port 50803.

I changed the builtin web server to run under a fixed port and adjusted my "Start URL" to use that port as well. project -> properties -> web -> "Servers" section -> "Use Visual Studio Development Server" -> specific port

For me the issue was that I had "Optimize code" enabled in the Build tab of my project's settings.

I am using VS 2008 and I got this error. I tried everything else suggested here and on some other web sites but nothing worked.

The solution was quite simple and there were two other solutions mentioned on this page that put me in the right area.

1. Go to Project menu and click on Properties (you can also right click on the Project name in the Solution Explorer and select Properties).

2. Select Compile tab on the left.

3. In the "Build output path:" textbox make sure it that you have "bin\" in the textbox.

In my situation it was pointing to another bin folder on the network and that is what caused the breakpoints to fail. You want it looking at your project's current Bin folder.

This is how I fixed my problem, after cloning into different repositories, for Visual Studio 2015:

In Visual Studio:

1. Click Tools->Options
2. In the left pane, click Debugging->Symbols
3. Click "Empty Symbol Cache"

Delete the .xap file if your breakpoint aren't being hit. Inside YourProject.Web/ClientBin Delete YourProject.xap. I've have tried all above and stumble across this fix, works everytime. Wise to clean the project after deleting as well.

This error can also arise when remote debugging if you aren't debugging the most up to date executable. When you are remote debugging don't forget to move over new code to the remote machine after (re)building on your local dev machine!

Goto Project Properties -> Build -> Advanced...

In the "Output" section select "full" in Debug Info dropdown

Make sure you are running your program in DEBUG mode and not RELEASE mode.

Open the Web Application url from the Browser and then in the VS.Net IDE use Tools-->AttachtoProcess

then attach to aspnet_wp.exe.

The Debugger will start working

This is a common problem if debug is being disabled by the application, and often ran into if you have multiple transforms on the web.config... One way to solve this is to go to Build>Configuration Manager and make sure the Debug configuration is set for start-up... Pretty common to go from testing one transform to another, and thus, losing ability to break at specific points.

I had the same problem. Following worked for me

Go to the web application --> Properties --> Silverlight Applications

If you don't see you Silverlight application in the list there then click Add and select your Silverlight Application from "Project" dropdown and Add it.

By all means mark this down for not-being-an-answer, but this problem of breakpoints not being hit, for me, just fixed itself. After hours of deleting temp files, rebooting, reinstalling, arsing around with debug settings to no avail, it just suddenly started working. I was on the verge of insanity when, for no reason at all, we hit a breakpoint. Love inconsistent bugs, me.

Whenever I've had this particular error come up, it's turned out that the folder that Visual Studio is loading assemblies from is different from the folder the web-application is running from.

That is, the application server is running the application from

C:\dev\MyApplication\bin 

but Visual studio is debugging from

C:\dev\MyOtherApplication\bin (or something along those lines, anyway).

Note - for various reasons, I do my debugging with IIS as the application host instead of the dinky standalone gizmo that most people use. This could influence the usefulness of my answer!

Update:

For IIS the application server directory (i.e. C:\dev\MyApplication above) is the physical directory configured for the web application - this can be controlled by changing basic settings for the app.

For Visual studio the debugging directory (i.e. C:\dev\MyOtherApplication above) is the directory in which your svc files are found, usually the same directory as your csproj project file.

One possible scenario is that if your ASP project is referencing some code in an Application(rather than a dll) then the symbols won't be loaded.

I had to change the referenced application to a Class Library temporarily while I debugged the code.

I tried renaming the .pdb file in obj\debug folder and did a clean solution and rebuild.
It created a new .pdb file and I was able to hit breakpoints correctly.

I had this very issue when at a client where - for each application solution - they copied most shared assemblies to a "References" folder, then added them to the solution both as "Solution items" and as a "Project" within the solution.

Not sure yet why, but some of them were debuggable, some not, even though in the References settings for the assemblies the correct full paths were specified.

This unpredictable behaviour alomst drove me mad :)

I solved this by removing all the assemblies from the "References" folder for which there were projects with source code, and keeping very good track of version information for shared assemblies.

The problem for me turned out to be that the Properties->Build->Optimize code checkbox had been turned on in the Debug configuration. Turned it off, rebuilt, and debugging worked as normal.

What i did to fix this issue was in the page where my break-point was not hitting, i selected the folder > add an existing item and then select the item from its save path. This allowed the break point to start working.

I had the same issue and after googling I found two typical solutions for this:

1. Make sure the Silverlight debugger is activated in the .Web project. Open up the project properties and select the Silverlight debugger under the "Web" tab.

2. Restart Visual Studio and delete all bin and obj folders.

But none of these worked for me. Then someone mentioned far down a thread to try using IE as the browser instead. This made debugging and breakpoints work again!

Edit:

Later I have struggled with IE9 not working, because it attaches to the wrong process. Instead of manually attaching to the correct IE process every time, I found a neat trick:

• Right-click one of the generated pages in the .Web project (.html or .aspx)
• Click "Browse with..."
• Set IE as default browser (will only affect Visual Studio's choice of browser)

Now, Visual Studio will launch IE when running the .Web project and attach to the correct process. That should do it.

For those reading that are using Visual Studio 2008, not Visual Studio 2010 and are getting this error. The answers above did not help me in this situation, so I'm sharing my experience.

If you're debugging an IIS Web application in Visual Studio 2008 by attaching to the w3wp.exe process rather than using the ASP.NET Development Server for debugging (start with debugging), this might be your issue:

Visual Studio might be still referencing a symbol file (file used during debugging) from your dll from an IIS process that is out of date. And that symbol file has been recreated by a .NET source code recompile but the IIS process is still referencing the old symbol file.

To fix:

Just stop debugging in Visual Studio, restart the web application, and re-attach to the process. Then the breakpoints should turn from yellow (when you see this error) to red again.

========================

More things to try (found new situation today):

Do each bullet in the link below ONE AT A TIME, but repeat my steps below with each one you try.

http://carnotaurus.philipcarney.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same

1.) Stop debugging (press red square icon) in Visual Studio
2.) Clean Solution
3.) Build Solution
4.) [INSERT BULLET INSTRUCTION HERE]
5.) Tools > Attach to Process (or start with debugging)
6.) Start the program that you're attaching to, and run it such that your code will get hit

6 explained:

If attaching to nunit.exe, then open NUnit and run a test so your breakpoint will be hit

If attaching to w3wp.exe (IIS site), then open your site in the browser and go to the page that will hit your breakpoint

EDIT:

Today I noticed that if you try debugging on a project that is not set as the start-up project, it will show this. When you attach to your w3wp.exe process, it thinks its debugging on the project that is set as the start-up project. To resolve, just right click the web application project, and choose "Set As Start Up Project". Then try re-attaching to your process.

I had the same problem, I was debugging my project, and i had to right click the project and select "new debug instance". I only needed to do this once, then after that it worked as normal.

Another anecdote which might be useful-

I encountered this problem when one of my projects was using file references from a Release output folder. When the build results were placed in a Goods folder, these Release dlls were overwriting the Debug dlls.

The solution was to make sure in the csproj file, my reference's HintPath was

<HintPath>..\..\Core\Goods\$(Configuration)\MyFramework.dll</HintPath>

and not

<HintPath>..\..\Core\Goods\Release\MyFramework.dll</HintPath>

I took the easiest path, actually in my multiple projects solution, including one class library, I had an issue with a .dll file created by that class library project which was not allowing me to have breakpoints while executing, because it was not building for some reason, I separately build that project and referenced it's output .dll and now the breakpoints are functional

Not sure, maybe this helps you; if not you then someone new like me just because it worked for me:)

For my WPF app, I deleted the application folder, did "Get Latest" from source control again, and rebuilt. All breakpoints working great now.

I debug by attaching to IIS. I grabed the production web.config for some new settings, and forgot to update the web.config to enable debugging.

Make sure the element has the debug setting to to true. In other words:

<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">

The solutions to the same problem in my case was the following combination of steps:

1. Solution --> Properties Select multiple startup projects select Start action on the projects you need to debug.
2. Removed the service from Service References and clean up the solution.
3. Rebuild the service project
4. Added it back to the Service References
5. Clean up the solution and rebuild it.

Had the same problem

For some reason, one of the DLLs was registered in the GAC, therefore it always had a different version than the code.

Once I removed it from the GAC, problem was solved

The reason for what you faced is that the PDBs ("PDB stands for Program Database, a proprietary file format (developed by Microsoft) for storing debugging information about a program) are not up-to-date, this may be due to some reasons:

1- As Bevan said, you may be debugging another application!

2- You are debugging another version of the same application. For example, you attached a previously built application with the current version of the code for debugging without (re)building it.

Cleaning or Rebuilding the Solution solves such problems for me.

To make sure the problem is not yours, try debugging the same application with VS 2008 (I am afraid it may be a bug in VS 2010 -- it is still beta!).

My problem was a "return" middle of the code. so after return breakepoint won't work.

I had to manually uninstall all instances of the .dll from the registry, and all instances of the .dll from my local drive. Uninstalled/reinstalled my app and now im hitting breakpoints! Wasted a half a day doing this :(.

I had the same problem - lost lot's of time trying to get debugging working in Visual Studio.

It ended up being Nuget - I had 3 versions of Newtonsoft.Json (across 7 C# projects). The solution would compile but wasn't debuggable.

I fixed the issue by running the following in Nuget's Package Manager Console:

PM> Update-Package Newtonsoft.Json

The scenario is this: a particular project is your start up project (e.g. has the Main method). That project is referencing other projects in your solution. Breakpoints in the other projects aren't getting hit.

Quick solution: when you build your solution, look in the Build output path (usually bin\Debug) for the start up project. Look at the DLL and PDB files for the projects you're referencing. Make sure their last modified date is the date you last built your solution. If they are not, then copy them from the Build output path for each project into your start up projects Build output path. For example:

Project A has Main. It references Project B. Your breakpoints aren't being hit in Project B. Copy the DLL and PDB file from Project B's Build output path to Project A's Build output path. Then run your solution. The break point will now be hit.

Now you need to figure out why Project A isn't copying over Project B's DLL and PDB file. The answers here cover most scenarios. One scenario not touched is making sure your projects and solution are binded to TFS properly. I had some projects binded and some not binded correctly. That caused the issue for me. Once I fixed that, the problem went away and I no longer had to copy over the DLL and PDB files.

Okay- here we go:

(In a "silverlight app": please check first that silverlight is checked in "web" in your server project "properties"- If that didnt solve it then try this beneath)

On first time do: run this first: devenv.exe /ResetSettings and 1: In top menu click on debug tag 2: click options and settings 3: In "debugging" and under "general" find "enable .net framework source stepping" 4: Tick the box. 5: And now all the symbols will be downloaded and reconfigured :)

If it happens again after the above just clear the folder where the symbols are:

1: In top menu click on debug tag 2: click options and settings 3: In "debugging" and under "symbols" find the button "empty symbol cache" and click it.

Right click on solution --> Properties

Look under Common Properties --> Startup Project

Select multiple startup projects

select Start action on the projects you need to debug.

I had the same problem but in VS2013 for a Web App. For me, the answer was to update the Build Configuration for the solution:-

1. Right-click on the Solution and choose Properties
2. Select the Debug configuration
3. Select "Configuration" under "Configuration Properties" in the trivet
4. Check on the "Build" box for each project you want to debug

Once I did this, all of my breakpoints started working.

If you are having problems with Silverlight projects the solution can be fairly simple. According to my experience in many cases debugging symbols are not being loaded due to the new ".xap" files not being deployed to temporary folder (either internal VS Cassini or IIS Express). In this situation full rebuilds or resetting VS settings won't help. The easiest solution is just to delete temporary internet files within your browser. If you are using IE for Silverlight development and testing I would recommend switching on "Delete browsing history on exit" option in order not to have such issues in the future.

If you're debugging a web project, make sure the debug="true" attribute has been set in your web.config file:

<system.web>
    <compilation debug="true"   .../>

This is such a useful thread, a checklist of things to try for this pernicious problem. For me the one that worked was swapping to IE. It took me a while to realise as I was already using IE, I had the project's web properties set so that the start action was to start extenal program

C:\Program Files (x86)\Internet Explorer\iexplore.exe

with the command line arguments

http://localhost/MyProject -private

I needed the -private flag to stop IE caching the swf I'm working on. Switching back to 'specific page' from 'start external program' fixed the 'no symbols have been loaded' problem for me.

I tried lots of things. What worked for me. I made the Silverlight app the 'Set as Startup Project' by right clicking on the project. Then I tried to run it (which obviously failed as it relied on RIA Services to a web server that was not running) And then I reset the Web project as the Startup Project .. and hey presto .. it is all working.

I've just resolved this issue according to Deploying Silverlight Applications. (This answer is a duplicate of some others but I'll attempt to explain it more thoroughly.)

The problem is most likely that your Silverlight application is not being deployed properly to your web application on build / startup. This is a referencing problem - it's simple to understand but not obvious the first time you encounter it.

Just like any other project reference, the referenced project's output should be copied to the referencing project's bin folder in order to debug. For class libraries this happens when you right click and select 'Add Reference...'. For Silverlight, you should add a reference through Project Properties.

• Right click your project, and select 'Properties'
• Select the 'Silverlight Applications' tab on the left
• Press the 'Add...' button and select your Silverlight project from the dialogue box

This adds a reference to the Silverlight application from your hosting web app, and ensures that the xap file will be copied to the web app on build or deploy. That means that the current Silverlight app and its debug files are inside the application being debugged, and you'll be able to step through the code.

To fix this issue in Web.config I just had to add debug="true"

  <system.web>
    <compilation targetFramework="4.0" debug="true">

What helped me to find this solution has been looking at the Modules windows while debugging and saw that for my ASP.NET DLLs loaded I had: Binary was not built with debug information.

I had the same problem on Windows 7 and tried everything: cleaned DLLs, investigated modules' list, turned off "Just My Code", and so on.

The problem was solved after I've run Visual Studio "as administrator". Honestly. Why Microsoft couldn't just warn me that it's not running "as administrator"? It would save me some hours of work.

Try to set Silverlight Application Project as as a startup project: right click on project -> 'Set As Startup project. Then press F5 and see if you can catch breakpoints...

Try to delete browsing/temp data in your browser each time You make changes to silverlight application