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

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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!).

Answer 6

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.

Answer 7

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)

Answer 8

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

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

Answer 9

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

Answer 10

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

Answer 11

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.

Answer 12

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"   .../>

Answer 13

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.

Answer 14

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

Answer 15

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

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

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.

Answer 20

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.

Answer 21

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.

Answer 22

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

Answer 23

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 :(.

Answer 24

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.

Answer 25

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

Answer 26

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

Answer 27

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

Answer 28

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>

Answer 29

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.

Answer 30

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