31
votes

I am struggling to overcome this obstacle and I have high hopes that someone on SO can help.

enter image description here

When I set a breakpoint in my class library project. It appears as a normal breakpoint. When I start debugging my solution the breakpoint becomes hollowed out and has a yellow triangle with an exclamation point inside. The tooltip displayed when I pan over the breakpoint is, "The Breakpoint will not currently be hit. No Symbols have been loaded for this document."

This project is not an ASP.NET application, it is simply a winForms application.

I have taken over an existing winForms application with multiple projects in the solution. I have the project built and running in debug mode. I can stop at breakpoints in some projects but, I am unable to hit the breakpoints in other projects specifically my project that is of type class library.

What I have done thus far:

  • I have deleted all debug and release folders,
  • I have deleted the obj folder, and have rebuilt the solution afterwards.
  • I have restarted the VS2008 IDE.
  • I have restarted my computer.
  • I checked the Configuration Manager for the solution to ensure that my class project is included in the debug build, and it is.
  • I have checked the debug/modules for dll, although I am not trying to reference a dll.

Furthermore, I have followed the troubleshooting steps outlined in the SO posts:

the breakpoint will not currently be hit no symbols loaded

VS 2010, NUNit, and “The breakpoint will not currently be hit. No symbols have been loaded for this document”

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

Can't debug - “The breakpoint will not currently be hit. No symbols have been loaded for this document”

Fixing “The breakpoint will not currently be hit. No symbols have been loaded for this document.”

Additionally, I have read numerous posts found on Google from both MSDN and other locations, none of which fit my specific needs.

Some of these posts are:

Visual Studio 2008 "The breakpoint will not be currently hit. No symbols have been loaded for this document"

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

Breakpoint will not currently be hit. No symbols loaded for this document.

Debugger problem "The breakpoint will not currently be hit. No symbols have been loaded for this document

The Breakpoint will not currently be hit. No Symbols have been loaded for this document.

All of the posts I have read have been very informative, but none of the suggested solutions have fit my specific needs. Please let me know if more information is warranted. I have more links I can provide as references to what has not worked. As well as additional steps I have taken to attempt to solve this issue.

I am posting this follow-up to keep everyone aprised. I followed @Hans @ suggestion to call the project file in question.

I placed a dim frm as form = new ProjectInQuestion.FormInQuestion

and

this now has the assembly loading in the debug--> Windows->Modules

The new problem is more perplexing than my original issue. My breakpoints look fine, but are being skipped. There are no error evident at the breakpoint.

enter image description here

13
The solution to my specific problem was to instatiate an instance of the dll I wanted to debug by specifically diming an instance prior to my break point.Michael Eakins

13 Answers

12
votes

This may be an old question, but I wanted to answer it after I found a solution for this very problem because it was one of the most complete questions asked in regards to this topic.

Intro

My project is an ASP.NET application, but the base problem will happen on WinForms as well. The problem arises when a DLL is missing from the assemblies output. However, this same exception occurs if the DLL you are referencing then references another DLL that is not in the assemblies. Due to the way the operating system loads DLLs, the referenced DLL must be in the environment path, and not in your output assemblies.

Project A references DLL D. DLL D references DLL X. DLL D may be in your output assemblies. DLL X must be in your environment path.

The core cause to this problem is in the way the operating system loads native DLL's at >runtime. Native DLL's are loaded using the following logic which does not include the >Temporary ASP.net Files nor the applications /bin folder. This problem will also occur in >any .Net application if the Native DLL is not included in the /bin folder with the .EXE >file or if the DLL is not in the Path Environment Variable.

Personal Solution

I was using a DLL called DivaAPIWrapper.dll (Managed DLL for C#). I knew, however, that DivaAPIWrapper.dll needed DivaAPI.dll (Unmanaged C++) to operate. I placed DivaAPI.dll in all my output paths but I kept receiving this error. Only after I placed DivaAPI.dll in my environment path (C:\windows\Microsoft.Net\Framework\v2.0.50727) did it work. Please note: your path may be different if you're using a newer version of the .NET framework!

Complete Solution by Jerry Orman

See Link Here: http://blogs.msdn.com/b/jorman/archive/2007/08/31/loading-c-assemblies-in-asp-net.aspx

8
votes

I also faced same problem and found many solution from internet but solution works for me is listed below:

Its due to my application made in framework version 4.0 and i was trying to attach process with version below v2.0 so make sure your framework version with Managed code version as its shown below.

enter image description here

4
votes

This happened to me recently when attaching to a running process. The issue was that the debugging options were set to

Attach to: Native code

For my case, it needed to be:

Attach to: Managed code

3
votes

One thing I discovered recently and worked pretty nice!!!

The hosting application (the one that is calling your dll to be used) must have this line:

<supportedRuntime version="v4.0"/>

in the "WhateverApplicationItIs.exe.config" file, inside the <configuration> section.

Example: (See "..." as whatever the file has inside it and leave as is)

<configuration>
    ...
    <supportedRuntime version="v2.0.50727"/>
</configuration">

PS: try to match this version with the target framework set in your project properties. I believe 2.0.50727 is a good try for 3.5 Framework, and 4.0 for 4.0 Framework.

For me it just solved two different DLLs I was trying to debug in different applications.

1
votes

I have this happen all the time, like you said the breakpoint is not active until the DLL is loaded. It really doesn't matter though, because it has to load the DLL before the code can get to that point anyway. My breakpoints start this way but they always get hit.

1
votes

Check that you didn't change the processor at which you aimed to compile this project. I had, and when I changed it back, everything worked again. Apparently a change in processor makes it 'different than the original'

1
votes

I had the same Problem with VS2008 in a Vb.net-forms application where I called a dll in another project, loaded in the same project group. I found this simple solution: I loaded an instance in the form_load event like Dim pmg As New PMGExport.PMGExportNeu.

1
votes

Please check if Solutions Configurator mode on the toolbar (right next to Run button) is set to "Debug" rather than "Release"

1
votes

Hope this helps...

I was referencing a DLL that was in my bin\Release folder, even though i was in debug mode.

I copied the DLL to bin\Debug folder and when i ran VS, the breakpoint was hit.

1
votes

try this, In Vs 2008,Go to Tools->option->Debugging->General-> unchecked/disable 'Requires source files to exactly match the original version

1
votes

I have the same problem on vs2010, I resolved in flow steps:

  1. Right-click project
  2. Select the properties
  3. Select c/c++ ->General
  4. Set debug information format to program Database(/ZI)
  5. Check linker->debugging Generate Debug info is yes.
0
votes

Please check if Solutions Configurator mode on the toolbar (right next to Run button) is set to "Debug" rather than "Release" Worked for me thx

0
votes

Make sure debug mode is selected in Visual Studio, before you start debugging.

Check the dropdown, near to the Play button in Visual Studio.