Breakpoint is not hit in VS2017

Question

0.00/5 (No votes)

See more:

I've a solution which is ported from VS (Visual Studio) 2010 to VS2017 from one machine to another. I could debug while I can't. I need to know what's the problem. When running, I see the breakpoint marks get changed to include a warning, but I can't find what can be wrong. It seems that everything is ok. The code is in C#.

What I have tried:

I got sure that the DEBUG and TRACE constants are defined. I'm also using the Debug mode.

Posted 26-Dec-17 2:35am

ilostmyid2

Updated 26-Dec-17 5:21am

Add a Solution

Comments

[no name] 26-Dec-17 8:38am

"When running, I see the breakpoint marks get changed to include a warning": And the warning message is?

ilostmyid2 26-Dec-17 10:52am

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

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Answer 1 · 2017-12-26T04:12:00

Solution 1

Start by checking the build mode: is it set to Debug on the menu bar, or Release?
Then check how you are starting execution: F5 is debug, CTRL+F5 is execute without debugger.
Also check if you are trying to debug an assembly that is referenced as the Release version: if so, you can't debug into it easily.

Posted 26-Dec-17 4:12am

OriginalGriff

v2

Comments

ilostmyid2 26-Dec-17 10:59am

build mode is Debug. i use F5. i'm not going to step into assemblies. the line with the breakpoint is located in my own code.

Dave Kreskowiak · Answer 2 · 2017-12-26T05:20:00

Solution 2

You haven't explained a problem at all, nor given any of the error messages you're seeing.

But, I can tell you that the breakpoint changing to a little warning means that there is no way the code you tagged for a breakpoint will ever be hit because there is no code that calls the method you put the breakpoint in.

Posted 26-Dec-17 5:20am

Dave Kreskowiak

Comments

ilostmyid2 26-Dec-17 11:31am

as i told before, the warning is:
The breakpoint will not currently be hit. No symbols have been loaded for this document.
now what can i do? i see the PDB files there.

Dave Kreskowiak 26-Dec-17 12:09pm

Yeah, I didn't see that comment you put in until after this was posted. It would have been nice had to put that information in the original post.

The PDB files are apparently not where VS is expecting them, probably because this a messed up conversion. The paths between where the project was on the old machine are different from where they are on the new one.

So, you can try doing a Clean Solution and then Rebuild Solution (both under the Build menu.)

Beyond that, you can open the .SLN and .PROJ files in your project folder and inspect them for the bad paths on your old machine, replacing them with the good paths on the new machine.

ilostmyid2 26-Dec-17 13:25pm

the directories hierarchy is the same. i did a clean and rebuild with no success.

Dave Kreskowiak 26-Dec-17 15:02pm

I said nothing about the directory hierarchy. I said OPEN THE .SLN AND .PROJ files (notepad) and examine them for the old paths, including DRIVE LETTERS.

ilostmyid2 1-Jan-18 11:53am

they're not absolute paths. so include no drive letter. they're relative paths.

Dave Kreskowiak 1-Jan-18 12:26pm

Well, I couldn't tell you what's going on then.

I'd attack the problem by starting a new project and dragging and dropping the source files from the bad project folder to the Solution Explorer window in the new project.

ilostmyid2 1-Jan-18 13:17pm

omg! i copied the whole solution from network drive into a local drive and the problem was resolved! why? the drive is essentially provided by SFTP Net Drive which is mapped from a linux machine. maybe i've to change the settings of Windows/SFTP Net Drive? maybe the problem would happen even if the network drive would be a mapped drive from a Windows share?

Dave Kreskowiak 1-Jan-18 13:24pm

You never said you were running this from a network drive.

That makes all the difference in the world because, by default, managed code running from a network source (ANY network source!) is NOT TRUSTED. It runs in a very restricted sandbox.

ilostmyid2 1-Jan-18 14:13pm

I didn't think this may be the cause. A drive is a drive. If it's trusted enough to run/debug a program, it should be trusted to access the PDB file for this purpose!

ilostmyid2 1-Jan-18 14:15pm

now what can i do to introduce network as a trusted source?
MS better not to make barriers than making the world a safer place!