VS2012 断点没有被击中

Question

I have a class that looks like this:

public class MyService
{
    private MyService(){}
    public static string GetStuff()
    {
        var stuffDid = new MyService();
        return stuffDid.DoStuff();
    }
    private string DoStuff()
    {
        //do stuff
    }
    //other private helpers

}

Obviously I left a lot out, but that's the general shell.

Now, I have a unit test:

[Test]
public void MyTest()
{

    var results = MyService.GetStuff();
}

I set breakpoints on my unit test, and I can see that results has data. However, I set breakpoints literally all over MyService and nothing gets hit unless I put them on a curly brace. Which I can't understand since results has data, my return statements in MyService should be getting hit, right?

Am I missing something? Did I completely forgot the most basic rules of something? How come nothing in MyService gets hit? And if I manually step into it with F11 , it just hops around and doesn't even go through every line like I would expect. Also when I step through manually I tend to hit certain code after I should have hit it originally. And any switch statements seem to default to whatever the first option is, even though the value being switched should CLEARLY enter a different case .

I've even tried making MyService constructor public and taking away all static methods, and it still doesn't work.

My Tests and 'Core' code are in the same solution, but different projects( Test and Core , respectively). Other tests don't have an issue hitting break points in Core , only this on particular test (the only test that is testing MyService ).

I've deleted my PDB files and cleaned solution. Still nothing.

Answer 1

Some ideas.

1. Make sure it's a debug build and not release
2. Turn off optimizations in your project properties if they are on
3. Try inserting Debugger.Break() in your code instead of a breakpoint in VS
4. Make sure breakpoints are enabled (Debug->Windows->Breakpoints toolbar), and breakpoint symbol should be solid
5. Execute your application. Load Debug->Window->Modules window. Check your assembly to see if symbols are loaded. It may give a relevant status message if not.

Have you been adjusting the date on your computer at all? This can really screw up a build process. If so, delete all your obj/bin folders manually and recompile.

Answer 2

It could be beacuse you are only debugging 1 project not both Test and Core

You can set VS to debug mutiple projects at once, you can do this by right-click your solution > Properties > Common Properties > StartUp Project

Here you can set "Multiple Startup Projects"

Just set both Core and Test to start. This may solve your issue.

Answer 3

It turns out this was related to Code Coverage being on.

Turning it off fixed the issue.

You can find out how to disable code coverage by following below link

Disable code coverage

Answer 4

I have a very specific scenario that resulted in the apparent issue of "Breakpoint not being hit".

Since no other answers here mentioned it, I will add mine in the chance that it will help someone who had the same issue.

The solution, in my case, was silly, and with as much LINQ as I use I should have figured this out sooner. When running a method that returns an IEnumerable, where the return statements contained within are actually yield return statements, then that method will not be executed when you call it.

It will actually be executed when you call another method from that IEnumerable object, such as ToList() or Count() . Only then will the method be executed and the breakpoint reached.

Answer 5

Just make sure that you have build your assembly with the debugger symbols.

This option has to be filled with "full":

Right-Click your project containing your code file with the break points not getting hit. Choose "Properties".

After project properties have been opened, choose "Build" tab. Watch out for the "Advanced..."-Buttom at the bottom of the tab page. (Within the "Output"-Group")

Click this button and choose "full" for the "Debug info" property. This should be a reason for breakpoints not getting hit. Visual studio uses the symbols saved in the pdb-files to find the exact position of the break point. If these files are not created, no breakpoints are hit. Maybe you disabled the creation of these files in order to tidy up your project file structure. This was a situation I recognized that I need these files.

Answer 6

I've recently had the same problem and was smashing my head against the wall.

The answer turned out to be pretty silly: Somehow my test project got out of sync with the main library project. I was building the debug versions of the test and library, but the test project copied the library from the bin/Release folder. I just recreated the project reference and everything was fixed.

PS It was even criazier: the debugger went inside a library function, but somehow skipped one line in the middle of it.

Answer 7

You need to make DoStuff static.

private static string DoStuff()
{
    //do stuff
}

Answer 8

Your code indicates a "service", which could be running as a separate process. If that's the case you can have your assembly loaded, so breakpoints would be solid red circles but another copy of the assembly, running in a separate process is actually handling the requests.

• check Task Manager for possible offenders (processes that may be hosting your service). Kill them while debugging to confirm the calls fail.
• Try using Debugger.Break();
• Create a debug log file, upon loading output to the log the entry process and assembly names. Make sure your log is either a different file each time to avoid async access issues.

Answer 9

This sounds like the pdb files are not updated in your test sandbox.

1) Ensure that you are in debug mode.

2) Can you try and include a deployment item for the pdb files explicitly?

• You said that you can attach a debug point in your test project.
• Once you have hit the debug point in your test project , check to make sure the pdb files with the latest time stamp is present in the Out folder of your sandbox.

3) If 1 and 2 fail , I have found that sometimes visual studio requires a restart :)

Answer 10

1. Clean the solution and rebuild and also do the start up project.

2. Can you please have a quick look at the BUILD > Configuration Manager, just to sure what are the configuration properties are set up. If it is development then you might have to adjust the Project Properties -> click advance setting -> change debug info to 'full' in [output tab].

3. you can also follow step two even it is not development mode

Answer 11

I had this happen in a 1 project out of 25 which were all in the same solution. The other projects honored breakpoints but this 1 didn't. I removed the project from the solution (delete, not unload) which broke all references to it and then added it back to the solution and that worked!

If that doesn't work you may want to recreate the problem project from scratch and add that new project to the solution.

The best explanation I have for why this worked apart from pure luck is that we migrated projects from one version of VS to another many, many times over the years and maybe one of those migrations caused this problem.

Answer 12

You could try to add a Thread.Sleep(5000) in GetStuff method and use Attach to Process

Visual Studio > Tools > Attach To Process and see if breakpoints below that line gets hit.

Answer 13

如果它处于发布模式，则将其切换到调试模式。

Answer 14

I know from experience that Visual Studio does not have a clear method of debugging services, especially Windows services. Try adding some code to GetStuff to print to a text file, this way you at least know the code is getting hit. When creating services I often fall back on this method for testing.

Answer 15

I ran into a similar issue. It turned out that for me it was a bad migration from VS2010 to VS2012 with the *.testrunconfig file. I deleted the old one and set up a new one to resolve the issue.

Answer 16

VS behaves exactly the way you described (not hitting the breakpoints, hitting the code you're not expecting to hit when stepping through) when it uses .pdb file which was generated using the source code somehow different from the code which is used upon debugging. I can't guarantee that this is your case, but I've observed such behaviour many times when I needed to step into the code which was supplied as a pre-built library which was generated against an older/different code with same filenames/symbols.

Answer 17

Maybe your Test project is referencing an older Core binary, rather than the Core (source code) project?

Try re-adding the reference in your Test project:

Go to your Test project and remove the reference to the Core project.

Now select the References folder and right click it and select the menu option to add a new reference. When in the Reference Manager dialog, make sure you are selecting Solution and then Projects on the left. Then in the middle of the Reference Manager dialog, select (check) the Core project.

Try debugging again and see if that helps.

Answer 18

Some more stuff to try:

• Check if the loaded symbols match the debugged executable:
  Open a VS command prompt and cd to the directory where the executable you debug resides. Then do a dumpbin /PDBPATH:VERBOSE MyServiceExecutable.exe and scan the output for "PDB age mismatch" (Ref: http://msdn.microsoft.com/en-us/library/44wx0fef.aspx )

• Not sure about VS 2012, but older versions of VS had a bug where the wrong source file would be displayed, provided that you have two source files in your project that have the same name, even when they are located in different folders. So if your project contains another source file with the same name, see if renaming one of them helps. ( Update: Seems VS 2012 is affected too .)

Answer 19

Silly me the Test Project wasn't set to be built:

Answer 20

This one's pretty obscure :

Make sure you don't have two virtual directories with different App Pools pointing to the same physical location on your harddrive. During development this is something that can sometimes happen for testing, or by mistake.

I'm not 100% clear on the technicalities but I had two AppPools and two virtual directories and no breakpoint was ever hit because I presume the physical path was somehow mapped in IIS/Visual Studio to the other apppool and not the one that was actually executing.

Answer 21

I have the same issue. Maybe my solution will help you to solve your problem. Just in "Attach to Process" for option "Attach to" select value "Avtomatic: Native code". Best regards.

Answer 22

First try rebuilding your project by right mouse click the project > Rebuild If that doesn't work, try a clean of the project (right mouse click on the project > clean)

If that didn't work check this:

Right mouse click your project
select [Properties]
select the [Build] tab
make sure [Define DEBUG constant] and [Define TRACE constant] are checked
Click the [Advanced] button at the bottom of the Build tabpage
Make sure that [Debug Info:] is set to [full]
Click [OK] and rebuild the project ;-)

Hope that works for you! (step 6 generates the .pdb files, these are the debugging symbols)

Answer 23

To debug step-by-step, you must do two things. First you must set the break point, then you must attach the debugger to the process running your code. If you are running IIS Express and you have 64 bit machine, then you need to attach iisexpress.exe that is running your code. If you press CTRL + ALT + P, you'll get to the attach to process window. After attaching, the break point should be hit if the code matches.

Answer 24

In Unit Tests, I was not hitting breakpoints, and realized I was Running the test and not Debugging the test. At the top of the Test Explorer are the options "Run All", "Run Failed", "Run Passed", etc. When you Run a test, breakpoints are not hit. To Debug a test, in the Test Explorer right click on the test or group of tests and select Debug Selected Tests.