"The breakpoint will not currently be hit. The source code is different from the original version." What does this mean?

Question

When debugging in Visual Studio, sometimes I add a breakpoint but it's hollow and VS says "The breakpoint will not currently be hit. The source code is different from the original version." Obviously this prevents me from being able to debug.

What on earth does the message mean? What original version? If I've just opened up the solution and not made any changes whatsoever to the code, how can there be an 'original version'?

are you opening a project written in another version of visual studio ? — Mahesh Velaga, Mar 18 '10 at 10:08
It's a website project. There should be no need to explicitly build it. It should compile on use. I suspect VS can't build the website, but it's not telling me that! Mahesh - no, all the same version of VS. — David, Mar 18 '10 at 11:25
On my case ..I have different releases of same code (for example test.cs on Live version and devolopment version ..when i opened devolopment version and put breakpoint on test.cs gived same error but i figured out that I put breakpoint test.cs class which related to live version sln not devolopment so check the cs has already under building solution) — dankyy1, Aug 28 '13 at 11:07
Deleting bin and obj directories than rebuilding worked for me. — Aycan Yaşıt, Nov 28 '14 at 10:18
I've answered a similar question here: https://stackoverflow.com/a/58397022/2171441 — apohl, Oct 16 '19 at 14:46
Late to the party but may offer some additional insight. I had this error and it was on a web API. The issue was caused by me updating my virtual directory for the project but forgetting to update the URL in my POST calls with the new virtual directory. — Reg Smith, Dec 10 '19 at 15:04
In my case I had copied my project to a different folder, but the VS editor was still having me edit the source files in the old location so my changes weren't being built. Just had to copy the sources again and re-open the files from the new location so they actually got built. — LunarGuardian, Dec 12 '19 at 16:18

score 317 · Answer 1 · edited Jun 11 '14 at 01:29

317

As it says, the "source code is different from the original version".

Right click on the project folder inside the solution explorer and choose to Clean. Build a new version of the project and the breakpoint will work again!

edited Jun 11 '14 at 01:29

Veedrac

58,273
15
112
169

answered Nov 09 '10 at 13:52

André Alves

367
1
3
2

141

Using clean does not always work. I had to manually delete everything in my bin folder to get it to work again. – Carra May 04 '12 at 13:53
3

I mistakenly had a reference to a DLL in my bin folder. Correcting reference path fixed. – Brad Urani Dec 12 '12 at 19:08
I mistakenly was editing the Global.asax file in the wrong project, not the project that was being tested. Obviously a problem! – Brett Apr 24 '13 at 19:19
Without Cleaning, you can right click on the project in solution explorer, and just click rebuild directly – Chris Sep 12 '14 at 16:56
48

For me, even deleting the bin and obj folders didn't work. I had to restart Visual Studio as well. – d512 Nov 05 '14 at 03:13
1

Spent allmost a day to find the solution. Thanks a ton for providing a solution. – Unknown Oct 13 '15 at 21:16
12

I've closed VS, deleted all bin and obj folders, rebuild everything, double checked build configurations, build is succeeding. No dice. Simple things shouldn't be this complicated. >:| – snarf Nov 01 '15 at 18:13
Check your IIS config inside the project properties. This trips it up for me a lot. – g_uint Nov 16 '15 at 10:28
Mine is a website, so I can't Clean it – Ortund Jun 14 '16 at 15:06
2

It's still not working after deleting files from bin and obj folder. – Naveen Kumar Dec 04 '17 at 09:45
Note: this approach did not work for me. What did work however, was ensuring that all the imported projects had their references in order, and also looking at the properties of the solution and ensuring that all projects had the same platform and were checked for Build. – Bob McBobson Jun 17 '19 at 11:18
any permanent fix? I have to rebuild every time, which is super slow. – Emil Apr 08 '20 at 21:19
That did not work for me. This solved the problem: 1. Clean solution. 2. close VS. 3. Delete .vs 4. Search obj and delete all of them. 5. Restart VS. 6, run. Bob's your uncle. – Doug Null Sep 02 '20 at 16:25
I,ve selected Solution configuration as Debug and its start working for me. – umeshkumar sohaliya Sep 07 '20 at 12:42

score 142 · Answer 2 · edited Jun 11 '14 at 01:26

142

If you have unchecked the DLL project in the Debug build configuration, your new code will never be built!

Go to Build --> Configuration Manager ... (in VS2010) and check if the project with the code you're trying to debug is checked for the current build configuration.

edited Jun 11 '14 at 01:26

Veedrac

58,273
15
112
169

answered Jan 13 '11 at 22:01

Oliver

9,239
9
69
100

Thanks for the suggestion Oliver. That's definitely not been happening here, I would notice quite quickly if one of my projects wasn't building. – David Jan 14 '11 at 14:59
4

I had exactly the same issue, only did not had anything unchecked. it was just build for x86 in that dialog, while my local machine is x64! So I selected the `Any CPU` option and it works again. – JP Hellemons Jul 11 '12 at 07:28
3

Removing projects from the debug configuration without a valid reason should be a cardinal sin, as that config may well be used by the CI build machine (I know it is here), so ultimately could pass that when it should fail. I know it could be one of many build steps but still... @Oliver I hope the team member bought you some biscuits ! :) – Fetchez la vache Oct 17 '13 at 09:47
I had this problem when I switched to build for x86 instead of AnyCPU. It removed projects from being built for some unknown reason. – Adam Nov 20 '14 at 06:47
The project is listed for Build in configuration manager so this hasn't helped me I'm afraid :( – Ortund Jun 14 '16 at 15:07
My project was listed for Build, but this gave me the hint. Somehow my "current" configuration was one of the non-development builds where this project was indeed not included. Switching back to "Debug" in Configuration Manager fixed it. – S. Baggy Mar 28 '19 at 04:58

score 46 · Answer 3 · edited Jun 11 '14 at 17:04

46

For me it was while working on a WebSite project. After cleaning up these temp folders I got the proper compiler errors back:

C:\Documents and Settings\%username%\AppData\Local\Temp\Temporary ASP.NET Files
C:\windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

I finally resolved the problem when I discovered that a class file I had intentionally moved into a subfolder, somehow reappeared in the root folder. VS was using that one while I was editing the other.

edited Jun 11 '14 at 17:04

user247702

23,641
15
110
157

answered Jan 09 '12 at 18:32

AnthonyVO

3,821
1
36
41

2

Emptying out the temporary files in the windows directory worked for me, cheers! – ChrisFletcher Apr 22 '12 at 12:27
8

I just wanted to add a similar answer - make sure, that no old copy of your project's dll is lying around in any of the temporary folders ASP.NET uses, like **C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files** - as mentioned - but also **C:\Windows\Microsoft.NET\Framework_64_\v4.0.30319\Temporary ASP.NET Files**. I use [Everything](http://www.voidtools.com/download.php) to [quickly search for those copies](http://shades-of-orange.com/post/2012/10/05/Everything-has-stopped-working). – Oliver Jun 19 '13 at 09:14
14

Just a quick hint: typing `%localappdata%` in search box takes you directly to `C:\Documents and Settings\%username%\AppData\Local` – dav_i Sep 09 '13 at 14:08
1

Can confirm this worked for me in Visual Studio 2013 on a webservice project. – Moeri Oct 01 '14 at 12:29

score 43 · Answer 4 · edited Jun 11 '14 at 16:51

43

Go to

Tools
- Options
  - Debugging
    - General

Uncheck Require source files to exactly match the original version

edited Jun 11 '14 at 16:51

user247702

23,641
15
110
157

answered Jan 09 '12 at 04:17

Rachmad

31
2
2

24

@Rachmad This solution works. But it seems not the complete solution, because it means our source files is not exactly matches the original version – onmyway133 Jan 31 '13 at 08:20
This is exactly what I was looking for by @entropy is right. While this allows the breakpoints to be set, the fact is that the source being used isn't matching the pdb being used. The best solution is to fix that. In times that cannot be done, this works great. – JamesG Feb 05 '13 at 20:47
3

Even with this unchecked, execution doesn't hit the breakpoint and the error persists – Ortund Jun 14 '16 at 15:08
19

This is NOT a solution to this problem but a workaround. Obviously I don't want to work with outdated files in the debugger. – Obi Wan Sep 01 '16 at 20:21
2

@ObiWan Not obvious. I like to make minor edits and continue debugging even knowing the source and build are different. – Alan Baljeu Aug 09 '19 at 20:26
This actually solved my problem. It didn't cover it up, it SOLVED it. My deploy process REQUIRES the DLL to be mutated in a way that the debugger doesn't recognize it but it DOES work if this setting is disabled. Don't assume this isn't the solution for anyone. This is 100% the specific and only solution to my issue. I wish I could upvote this answer twice for ~*answering the question as asked*~, something SO users seem to struggle with. – KatDevsGames May 05 '23 at 22:02

score 42 · Answer 5 · edited May 23 '17 at 11:47

42

Did you ever do this?

Would you like to continue and run the last successful build?

If you ticked the box and pressed "Yes" you will get the last successful build running even though your project does not compile. This means that whenever you set a breakpoint, you will get that error.

Try changing this value:

Tools
- Options
  - Projects and Solutions
    - Build and Run
      - On Run, when build or deployment errors occur: Do not Launch

edited May 23 '17 at 11:47

Community

1
1

answered Mar 18 '10 at 10:11

Codesleuth

10,321
8
51
71

I don't *think* I had done that. Thanks for the link though. It gave me an insight into what that prompt means! – David Mar 18 '10 at 11:27
14

Visual Studio had this option for decades now (at least VS98 had it). I never understood why anyone would want to run the last successful build. After all, if that was what I wanted, I would have launched it directly, since I couldn't debug anyway. Do not Launch would have been a more sensible default. – OregonGhost Mar 19 '10 at 09:16
7

I've used it a few times to run the project (for whatever reason, like just to show someone else) while I'm still in the middle of writing code that won't compile. *Sometimes* it's handy. Personally, I leave it disabled. – Codesleuth Mar 19 '10 at 09:24
5

Maybe if they had to show their superior when he suddenly came by. They could hit f5 and be like "you see, it works!" – Gigala Feb 10 '16 at 10:06

score 33 · Answer 6 · edited Jun 11 '14 at 16:51

33

Select Debug in Solution Configurations, instead of Release

screenshot of menu

edited Jun 11 '14 at 16:51

user247702

23,641
15
110
157

answered Jan 23 '13 at 12:48

AdiKonstantin

658
1
8
8

1

This was my issue. I had compiled in debug mode, changed the code, then later ran it in release mode. No wonder the debugger thought the code was different - the debug symbols *were* different. When I deleted the bin folder as others suggested, I got an error "no symbols have been loaded for this document." It was only then that I made the connection, and made my way to this answer. It needs more votes! – egbrad May 01 '13 at 19:08
It is possible for the project to be disabled for build even in the Debug build configuration. An examination of the build configuration is required, flip-flopping between Debug/Release configuration is pointless. – Asad Saeeduddin Jun 10 '14 at 15:34

score 27 · Answer 7 · edited Jun 11 '14 at 17:01

27

Pay attention to the "Output" window in VS. It will tell you what assemblies are loaded and when. You may see that an older version of your assembly somewhere in the folder is being loaded.

For example if you have multiple assemblies and you are currently trying to break in one of the support assemblies, the CLR will handle the assembly resolving, which may load another assembly file than the one you have referenced in the project.

edited Jun 11 '14 at 17:01

user247702

23,641
15
110
157

answered Mar 18 '10 at 11:14

Tormod

4,551
2
28
50

1

Also worth bearing in mind, but I don't think it's the problem here since I'm trying to break into a website project, not a class library. – David Mar 18 '10 at 11:28

score 26 · Answer 8 · edited Jun 11 '14 at 17:12

26

Closing Visual Studio and reopening the solution can fix the problem, i.e. it's a bug within the IDE itself (I'm running VS2010).

If you have more than one instances of Visual Studio running, you only need to close the instance running the solution with the problem.

edited Jun 11 '14 at 17:12

user247702

23,641
15
110
157

answered Nov 25 '13 at 21:57

Luke Whyte

31
2
5

4

Closing Visual Studio worked for me too. Also, with Clean / Rebuild actions. – danielB Jun 30 '14 at 08:31
3

This fixed the solution in VS 2015 – TaintedLemon Jun 09 '16 at 21:48
3

Fixed isue in VS 2017 – Daniel Fisher lennybacon May 26 '18 at 21:48
Fixed the problem in VS 2012 – seebiscuit Jul 24 '18 at 03:03
Fixed in VS 2019! Restart is the master solution for all computer difficulties :D! – VSB Mar 28 '21 at 13:41
This did not work and does not work. – Deepak paramesh Nov 02 '22 at 11:09

John Hatton · Answer 9 · 2018-01-12T16:23:51.180

25

A new way to get this problem has appeared as of Visual Studio 2017 15.3.1 through 15.3.5. If you are using EditorConfig, the charset=utf8 option causes these symptoms. The VS team has reproduced this and says they are working on it.

So one fix is to comment out your charset=utf8 line in the .editorconfig file.

Edit: This should be fixed as of VS 15.5.

edited Jan 12 '18 at 16:23

answered Oct 03 '17 at 15:51

John Hatton

1,734
18
20

Status is now "Fixed - pending release" as of two days ago (October 9, 2017). Which is good news, since UTF-8 is the only sane default for text encoding these days. :-) – rmunn Oct 11 '17 at 06:57
I also notice that the ultimate cause of this issue was apparently [this other bugfix](https://developercommunity.visualstudio.com/content/problem/22922/editorconfig-support-interprets-charset-utf-8-as-u.html), where `charset=utf8` was being interpreted as "UTF-8 with BOM". Changing that interpretation to "without BOM" broke some UTF-8 files that had the BOM in them. So if you run into this issue and the Visual Studio fix hasn't been released yet, try removing the BOM from the beginning of your text files and that may fix the issue. (This comment is *begging* for a Zero Wing reference... :-) ) – rmunn Oct 11 '17 at 07:01
This was the problem for me as well. Currently, this is not fixed or at least released yet or bug was re-introduced (version 15.4.2) – avidenic Nov 06 '17 at 09:54
2

This bug ist still (or again) existing in 2023. Short - charset in editorconfig and encoding of .cs file needs to be equal. – KCoon Jun 27 '23 at 13:24

score 16 · Answer 10 · answered Dec 06 '17 at 00:02

16

For me, none of the items solved the issue. I just added a new line of code inside that function, something like:

int a=0;

by adding that, I guess I triggered visual studio to add this function to the original version

answered Dec 06 '17 at 00:02

Nick Mehrdad Babaki

11,560
15
45
70

That actually did it for me (when none of the above, including cleaning and manually deleting bin and obj, did) – Christoph Mett Nov 14 '21 at 21:22

Mike Mooney · Answer 11 · 2014-06-12T15:48:02.967

12

This happen often also if you are using a file references to binaries (instead of project references to code in your project), and the compiled binary that you are referencing falls out of sync with the corresponding source code on your machine. This can happen because you downloaded a new version of the binary from source control without the new source code that went with it, or you have a few versions of the binary on your machine and are referencing an old copy, etc. If this is indeed the problem, it's a good reason to use project references as much as it practical.

edited Jun 12 '14 at 15:48

answered Mar 18 '10 at 10:29

Mike Mooney

11,729
3
36
42

I see what you mean, and that's worth bearing in mind for the future, but the source in question here is a website project, not a class library. – David Mar 18 '10 at 11:26
This is a common problem when picking up legacy code that leaves me scratching my head wondering which genius decided to reference a dll from a project in the solution that is only ever used by another project in the solution. *sigh* – Kell Nov 20 '17 at 11:31

score 9 · Answer 12 · answered Apr 03 '15 at 13:08

9

There is an almost imperceptible setting that fixed this issue for me. If there is a particular source file in which the breakpoint isn't hitting, it could be listed in

Solution Explorer
- right-click Solution
  - Properties
    - Common Properties
      - Debug Source Files
        
        "Do not look for these source files".

For some reason unknown to me, VS 2013 decided to place a source file there, and subsequently, I couldn't hit breakpoint in that file anymore. This may be the culprit for "source code is different from the original version".

answered Apr 03 '15 at 13:08

JBSnorro

6,048
3
41
62

I faced the exact same problem. Your answer did help me! Thank you! +1 – jweyrich Nov 04 '15 at 13:40
My file was indeed in there for some dark reason, I removed it but the breakpoint still is not working – GuidoG Jan 29 '22 at 08:54

score 9 · Answer 13 · answered May 26 '20 at 09:19

9

I just reloaded, clean and rebuilt works for me.

answered May 26 '20 at 09:19

Charan Darbasthu

13
1
4

score 7 · Answer 14 · edited Jun 11 '14 at 17:17

7

This can happen when the system time changes while debugging or between debug sessions, be it programmatically, manually or by an external program.

edited Jun 11 '14 at 17:17

user247702

23,641
15
110
157

answered May 06 '10 at 06:34

Tomi

11
1

I can't +1 this enough. I recently reinstalled Windows and didn't notice my system clock was off. Sure enough, this change screwed everything up, and rebuilding the entire solution/project magically fixed it. – Kyle Baran Dec 17 '14 at 21:48

score 7 · Answer 15 · answered Mar 21 '15 at 20:45

7

The problem is that your debug info is not in sync with your assembly. The solution is simple:

Go to your bin folder
Remove the .pdb files
Rebuild

Should do the trick!

(the weird thing is, a rebuild without throwing away the .pdb files doesn't always work. I can see the modified date being updated, but still somewhere in the chain (VS2013 debugger, IIS, assembly cache) this change is not detected)

answered Mar 21 '15 at 20:45

FrankyHollywood

1,497
19
18

1

Build->Clean Solution should also accomplish removing the files that need to be removed. – Dave Jun 29 '16 at 16:35
After huge amount loss of time lost because of this issue, this solution made the trick. Thx FrankyHollywood – A.D. Nov 17 '16 at 13:46

score 6 · Answer 16 · answered Mar 30 '15 at 18:19

6

If you have more than one projects in your solution, then make sure that the correct project is set as the StartUp Project. To set a particular project as the Startup Project of your solution, Right-click the project, choose Set As StartUp Project.

After I set my StartUp Project correctly, desired break-point was reached by the thread.

answered Mar 30 '15 at 18:19

displayName

13,888
8
60
75

Worth also noting that if your breakpoint is in a project that is NOT your startup project, and it CANNOT be made your startup project (because e.g. you need to have a different project be the startup one) you can (after starting the main one) right click and choose *Debug >> Start New Instance* of the project that has the breakpoint in that you want to hit – Caius Jard Mar 13 '19 at 16:10

score 6 · Answer 17 · answered Jul 28 '20 at 11:57

6

I'm with this error in VS2019 and I think that it starts to occurs when Windows has clock changed.

answered Jul 28 '20 at 11:57

rodcesar.santos

388
4
4

Oh thank you! I forgot that I changed the clock time to test something then this problem occured. Now the debug tool works fine. (VB 2008) – Kuro Neko Sep 13 '21 at 05:44

score 5 · Answer 18 · edited Jun 24 '21 at 16:09

5

This happens also when debugging a C++ project which loads a module that has been implemented with some CLR language (Managed C++, C# etc). In this situation the error message is misleading indeed.

The solution is to put Common language runtime (CLR) support configuration property to the startup project and recompile that.

edited Jun 24 '21 at 16:09

sergiol

4,122
4
47
81

answered Apr 30 '12 at 10:18

MaR

11
1
1

score 5 · Answer 19 · edited Jun 11 '14 at 17:16

I encountered this as well. The conditions that caused my issue:

I'm running a full IIS7 instance locally
I'm versioning my software into separate projects

I had caused this by opening a previous version (VS prompted to ask if I wanted to point to this instance in IIS debugging, I answered 'Yes'), then opening the current version (again responding to the IIS prompt with a 'Yes'), then attempting to debug in the previous version.

To solve, I merely closed and re-opened the previous and intended version, once again asserting it as the debugging source.

score 5 · Answer 20 · answered Oct 26 '17 at 16:37

For me the solution was hidden in the Advanced Build Settings of the project properties:

For an unknown reason it was set to none: setting it to full caused the breakpoints to be hit.

To get to this dialog, open the project properties, then go to Build, then select the Advanced... button at the bottom of the page.

score 5 · Answer 21 · answered Nov 10 '20 at 12:26

5

Exit from VS. -> Delete the .vs folder. -> Open VS. -> Run the Project.

Above solution worked for me. Hope this will help you as well.

answered Nov 10 '20 at 12:26

AKASH

416
1
7
19

score 4 · Answer 22 · answered Sep 28 '17 at 12:17

4

It happenned to be on Visual Studio 2017 after I added existing files to the project. This worked for me:

close the solution,
go to SolutionFolder\.vs\SolutionName\v15\sqlite3 and remove storage.ide
open the solution again

answered Sep 28 '17 at 12:17

laurian

739
6
18

Thank you for this solution! None before worked, and this saved my day :) – StefanaB Feb 12 '20 at 12:23

nurettin · Answer 23 · 2017-10-21T20:47:28.527

I experienced this in a 32bit build on vs2017.

Exactly none of the solutions worked for me. I restarted, I cleared IDE files, clean built solution, pulled from git repo and rebuilt the solution to no avail.

I was pulling in a 64bit dependency from nuget and as soon as I used the assembly, the sources were not being built into the final executable anymore and instead the IDE cached sources were being built.

I removed the nuget configuration, removed the referenced assembly, downloaded the source, built log4net manually, signed it, added it to a folder in my project, added reference to it, and I was able to debug again.

This was a pain, I hope it gets up in the answers list for all to see.

Edit: There was no error during build despite having the option "prompt on build error" being turned on in the IDE settings.

score 4 · Answer 24 · answered Apr 05 '18 at 10:09

I had the same issue in several projects in a layered architecture project and the problem was in configurations the build check box for the selected project hasn't been checked. so the issue was fixed for one project.

For one other layer it was giving this same trouble even the build is enable in the configurations. I did all the other options like restarting cleaning the project but non of them helped. Finally I unchecked the build checkbox for that particular project and cleaned and rebuild. the again marked the checkbox and did the same. then the issue was fixed.

Hope this helps..

score 4 · Answer 25 · answered Jun 02 '20 at 22:20

4

I've tried the proposed solutions but it didn't work.

In case you have multiple project, make the one you want to debug as the startup project.

answered Jun 02 '20 at 22:20

Badr Bellaj

11,560
2
43
44

score 4 · Answer 26 · edited Jun 11 '14 at 16:56

You can get this message when you are using an activator and the assembly you set the breakpoint into has not been loaded yet.

The breakpoint will resolve once the activator loads the assembly (assuming the assembly and debug symbols are up to date). A good place to look at is the modules window in the debugging menu. There you should look for the assembly which your file belongs too. First check that the assembly is loaded. Then, from where is it loaded? Then, is the symbols file loaded. Again, where is the symbols file loaded from? Finally check the versions of both.

score 3 · Answer 27 · edited Jun 11 '14 at 17:05

3

Try disabling and re-setting the breakpoint while running in debug mode instead of doing it before launching debug mode.

edited Jun 11 '14 at 17:05

user247702

23,641
15
110
157

answered May 15 '13 at 18:55

Mike G

4,232
9
40
66

score 3 · Answer 28 · answered Oct 17 '14 at 19:24

First I tried from command line;

deleting temp files from command line did work.

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files>rd /s root

When I disable "Enable Just My Code" option in Tools -> Options -> Debugging -> General

The problem resolved for me. It is a WCF application, was trying to debug an ashx page. http://blogs.msdn.com/b/zainnab/archive/2010/10/25/understanding-just-my-code.aspx

score 2 · Answer 29 · edited Jun 11 '14 at 17:11

2

What worked for me was to change the solution platform from x86 to Any CPU. After changing to Any, I set a stop address, ran the website, opened the page, clicked the button and it stopped. I closed the site, changed back to x86 and performed the same sequence successfully.

edited Jun 11 '14 at 17:11

user247702

23,641
15
110
157

answered May 15 '12 at 21:11

John

41
1
1

2

Perhaps the choice of CPU doesn't affect the problem at all and it's just the fact that it forces a rebuild? – jwg Jan 17 '13 at 10:52
It will use another bin folder, there probably was an old dll in your any cpu map. – Carra May 14 '13 at 09:30
I had this problem while active platform x86 (which I never used), switching back to Win32 solved the issue. The PC is a shared one so someone else set that platform for any reason. – Zac Mar 25 '15 at 13:31

score 2 · Answer 30 · answered Aug 19 '13 at 14:50

2

In my case, I was attaching to a running process in VS 2012. When attaching, you're given the option to debug in various modes (native, script, silverlight, managed 2.0, managed 4.0, etc). By default, the debugger selects the mode automatically. However Automatic does not always make the correct choice. If your process contains multiple types of code, be sure the debugger is using the correct one.

answered Aug 19 '13 at 14:50

silent tone

539
7
12

In my case I was attaching to w3wp.exe to debug .NET code but for some reason it was attaching the Script debugger which wasn't able to see my C# breakpoints. Changing it to the .NET debugger allowed my C# breakpoints to work. – Oran Dennison Sep 15 '14 at 22:41

score 2 · Answer 31 · answered Nov 21 '13 at 14:30

In my case, I was developing a Windows CE app, that tested against an emulator. The problem was that the executable wasn't deployed to the emulator, so the .pdb (in the development environment) was out of sync with the .exe (in the emulator), because the new .exe was never copied to the emulator. I had to delete the .exe in the emulator to force a new deployment. Then it worked.

score 2 · Answer 32 · edited Jun 11 '14 at 17:20

2

Under Windows 7, Visual Studio Express 2010, if you have activated the option Use compatibility mode for Windows XP SP3, this error may occur.

I unchecked the option and it worked perfect again. Right-click on the shortcut to VS or the executable, select properties and then compatibility.

edited Jun 11 '14 at 17:20

user247702

23,641
15
110
157

answered Mar 18 '14 at 14:18

Pete

1
2

1

What might be happening here is that your release configuration changes from x32 to x64 when you disable compatibility mode, and you might not have all of your projects selected for build in x32. Why certain projects are disabled for build in x32 is something you'll have to talk to your team members about. – Asad Saeeduddin Jun 10 '14 at 16:07

score 2 · Answer 33 · answered Jan 07 '15 at 11:52

It happened to me because I had other projects in the solution that weren't building. After I unloaded those problematic projects (right-click on the project in the solution explorer -> Unload Project), rebuilt the solution and ran again -- the breakpoint was hit!

score 2 · Answer 34 · answered Nov 02 '17 at 10:02

2

Make sure you are not in Release Mode when you try to debug.

answered Nov 02 '17 at 10:02

ComeIn

1,519
17
12

score 2 · Answer 35 · answered Sep 21 '18 at 18:23

For VS Code users:

If you hit this while trying to debug an ASP .NET Core application, make sure that the build task defined in tasks.json and whose output you can see in the Debug Console pane, runs successfully.

The debugging configuration defined in launch.json which references this task, will for some reason (at least under some circumnstances) continue to execute the defined binary even if the build task has failed, and since the build task has failed, that binary is going to be the last successfully built assembly.

I faced this issue after commenting a line of code and rebuilding. Resolved this by uncommenting that line then building the project and then again commenting and building the project. — Zuwaib Ansari, Sep 21 '20 at 12:31

score 2 · Answer 36 · answered Jun 13 '19 at 04:35

2

Intentionally break the build, meaning add some arbitrary text in the project that is out of sync when debugging. Attempt to debug and receive the exception. Now fix the exception and debug the project.

answered Jun 13 '19 at 04:35

AnxiousdeV

373
1
3
20

score 2 · Answer 37 · answered Mar 16 '20 at 21:59

Steps that helped me (VS Community 2017, 15.9.11).

Note that breakpoints will be lost after doing steps below.

Right clicked on the class file
Selected Exclude From Project
Right clicked on the project
Chose Add and Existing File
Navigated to pick the class file in question

score 2 · Answer 38 · answered Dec 26 '20 at 06:14

2

Sometimes you just need to change Solution configuration from 'release' to 'debug'.

answered Dec 26 '20 at 06:14

Tushar Kshirsagar

239
2
14

score 1 · Answer 39 · answered Sep 16 '14 at 23:29

If your debugged process contains multiple appdomains and the assembly is loaded into both, and one of them is loading an old copy (usually something dynamically loaded like a plugin) the breakpoint can appear solid, but the thread that should hit the breakpoint is in the appdomain with the old assembly, and never hits. You can see what assemblies are loaded and their path in the module window.

score 1 · Answer 40 · answered May 12 '15 at 14:37

Check to see if you have more than one file with that name in the solution.

I had this on a project that I took over from someone else. The breakpoint list was full of line numbers in Controller.cs, some active and some not. I found this question, and tried a few options, but when I double-clicked on the breakpoints, they took me to different projects within the solution. Because the files were called the same, they appear to be the same, but they aren't. The answer is of course then to ignore the warning, as they will become active if you get to load that other file.

Or in my case, looking at the other Program.cs than the console I am running! — ono2012, Jun 29 '16 at 14:14

score 1 · Answer 41 · edited Jun 04 '18 at 12:00

1

go to:

Tools > Options > Debugging > General > unchecked "Require source files to exactly match the original version"

edited Jun 04 '18 at 12:00

Shazvan Hanif

361
3
20

answered Apr 14 '16 at 06:10

Long Field

858
9
16

8

Doing that will cause the debugger to reach the breakpoint which code that is NOT the last version . So you will not test your updated code. – A.D. Nov 17 '16 at 13:38
Yeah, but sometimes MS gives files that are mostly correct (lines and variables that I'm interested in are correct), but for some reason they doesn't get matched. SMH. Anyway, this didn't work, at least in the current debugging session. I found the proper file and it did go into the file by saying it's fine to do so, but I can't move my instruction pointer move. Grrrr. – Adrian Mar 08 '17 at 17:29
5

This is a great way to get unexpected results. Debugging code looks correct, but isn't actually the code being executed. – Zac Faragher Oct 31 '18 at 05:03

score 1 · Answer 42 · answered Dec 17 '17 at 09:59

1

Maybe the dlls are being loaded from GAC.

You can uninstall the dll from gac, admin permission are required.

gacutil -u YourDll

answered Dec 17 '17 at 09:59

Xtremexploit

319
4
7

score 1 · Answer 43 · answered Nov 13 '19 at 10:33

I had this problem in VSCode, and the issue was that the file that I was looking at in the editor was not the same copy of the file that the project was building. I had cloned a repository for a C# library down into two locations, one which was open in the editor and one which was being linked by the project. If clean building isn't working for you, check that you are looking at the right copy of the file in the editor!

score 1 · Answer 44 · answered Apr 21 '20 at 08:28

1

I fixed that by first removing the file that's problematic.

Compile.

For some reason the program runs anyway. It shouldn't compile. It has errors and stuffs but it runs anyway.

I readd the file in problem. Run again. Somehow it fixed itself.

answered Apr 21 '20 at 08:28

user4951

32,206
53
172
282

score 1 · Answer 45 · answered Apr 28 '20 at 11:03

1

Because build's version changed (most probably you modified the source code), so recompile the solution and run the application again, after then it will hit debug break point.

answered Apr 28 '20 at 11:03

Anjan Kant

4,090
41
39

score 1 · Answer 46 · answered May 18 '20 at 04:41

My issue was a bit stupid. I had two copy of my project and I mixed files in visual studio.

Let s say you have projectX and projectY. These projects both contain myFile.cs. I opened projectX and edited myFile.cs. But this myFile.cs was belong to projectY . (It s possible to open files from different projects in visual studio) So in that case as warning says source code will be different than original.

score 1 · Answer 47 · edited Feb 15 '21 at 22:14

1

It works well - you must put unchecked in the checkbox "Enable Just My Code" as highlighted in below image:

edited Feb 15 '21 at 22:14

Amit Verma

8,660
8
35
40

answered Feb 15 '21 at 19:35

Pilar Mireles

96
5

Disabling this will enable debug info in some external code you are using. – Enrico Aug 29 '23 at 12:46

score 1 · Answer 48 · answered Dec 30 '21 at 16:27

1

I did the below for a similar issue:

Uncheck the option "Enable Just My Code" from the menu Debug -> Option -> General

answered Dec 30 '21 at 16:27

anand

577
6
11

score 1 · Answer 49 · answered Jul 12 '22 at 13:04

1

Make sure <Optimize>false</Optimize> is set to false in your csproj

answered Jul 12 '22 at 13:04

SerenityTn

171
3
11

score 1 · Answer 50 · answered Apr 13 '23 at 08:22

1

I had the same issue on Visual Studio 2022.

My breakpoints were not working only in one .cs fille.

The solution was to:

Copy the content of the problematic file in notepad
Delete the file from the project
Add new file with the same name
Paste the copied contet back

I hope this helps someone!

answered Apr 13 '23 at 08:22

SubqueryCrunch

1,325
11
17

This solved the issue for me as well, make a code change save & rebuild. – Enrico Aug 29 '23 at 12:47

score 0 · Answer 51 · answered Sep 11 '14 at 06:56

0

In my case the problem was ASP.NET debugging wasn't enabled under project properties>>Web

answered Sep 11 '14 at 06:56

voddy

950
1
11
21

score 0 · Answer 52 · answered Mar 31 '15 at 15:43

I had been messing with my csproj file earlier. So under project properties (VS 2013) > Web tab > Servers section > [dropdown], I had "IIS Express" selected when I previously had "Local IIS" selected. Once I corrected the settings to what I had before, the breakpoints worked.

score 0 · Answer 53 · answered Aug 25 '15 at 11:50

0

There are cases when recompiling and rebuild doesn't help to overcome this problem. One of other potential solutions could be deletion of source file with breakpoints from Solution Explorer and adding it again (e.g. by drag and drop from folder).

answered Aug 25 '15 at 11:50

Alex Smirnov

183
6

score 0 · Answer 54 · answered Mar 03 '16 at 11:33

For me; my website was running in an IIS Application under Default Website (http://localhost/myapp/) and the mapping for the IIS application was pointing to a disk path that was different to the source code I was working on.

To resolve; remap your IIS Application to the same path as the source code you are building.

(This can happen if you have multiple versions of the same application running from different locations on your disk)

score 0 · Answer 55 · answered Nov 23 '17 at 10:25

0

Also there is an issue with some versions of VS 2017(in combination with .editorconfig): Since 15.3, breakpoints don't work when the charset of the file is not the same as the one in .editorconfig (utf8 or utf8-bom)

answered Nov 23 '17 at 10:25

Guru Stron

102,774
10
95
132

score 0 · Answer 56 · answered Aug 07 '19 at 12:26

0

In my case, none of the other suggestions worked, however recloning my repository made this issue disappear.

answered Aug 07 '19 at 12:26

cbakos

323
2
9

score 0 · Answer 57 · answered Sep 11 '19 at 13:53

I got this problem after upgrading a project from netcoreapp2.0 to netcoreapp2.2.

I'd done this just by editing the TargetFramework entry in the .csproj file and neglected to also make the change launch.json.

"program": "${workspaceFolder}/src/MyProject/bin/Debug/netcoreapp2.0/MyProject.dll"

This meant that VS Code was always loading the old 2.0 version of the project. I only discovered it after deleting everything in /bin and /obj and then it wouldn't run at all until I spotted the 2.0 in the path above.

score 0 · Answer 58 · answered Oct 16 '19 at 20:21

I had this problem and that was because of a required Azure Cloud setting requirement from our DevOps team. When developing simply leave it out of the Web.config.

<httpRuntime maxRequestLength="102400" />

    <!--TODO #5 comment out for IIS Express fcnMode goes with httpRunTime above in other environment just in DEV -->
    <!--fcnMode="Disabled"/>-->

score 0 · Answer 59 · edited Dec 09 '19 at 01:48

0

In my case, I was assigned approx 120kb base64 value to a static constraint string field in a static class. After then this problem occurred. I was tried a lot of solutions but the problem was not solved until I removed this heavy loaded assignment.

My environment: MS VS Community 2017 Version 15.9.16

edited Dec 09 '19 at 01:48

dbc

104,963
20
228
340

answered Dec 08 '19 at 18:25

Fatih Eker

36
3

score 0 · Answer 60 · answered Jan 07 '20 at 20:18

0

I ran into this issue when using Local IIS rather than IIS express. The source of the files in IIS did match those in Visual Studio, however, I had to Recycle the Application Pool in IIS in order to have it consume the freshly built DLLs.

answered Jan 07 '20 at 20:18

th3morg

4,321
1
32
45

score 0 · Answer 61 · answered Apr 29 '21 at 16:56

Despite all the answers, my issue was actually different from all mentioned here!

Make sure your Properties -> Build tab -> Output path is pointing to the same place as all the other projects in your solution for the build configuration you have selected!

If your startup project is sending it's executable to a different folder from the dll you're trying to debug, you might have issues despite your build and visual studio working perfectly.

GuidoG · Answer 62 · 2022-03-05T10:53:21.237

In my case it was an wrong setting in the project/properties/build tab

I have a mainproject that references project xxx.dll
Breakpoint's in the referenced dll are not being hit.

The reference to the dll is set to bin\debug\xxx.dll in the library folder

So when I debug the mainproject, it goes to the folder bin\debug of the library to look for the xxx.dll.

But, in the library's properties, for some dark reason the Output path was set to bin\x86\debug in stead of bin\debug

Because of this every build of the library put the new dll in the folder bin\x86\debug in stead of in bin\debug

So VS always found an old dll of the library when debugging, thus the error was right, there was an different source.

So I corrected the Output path from the library to bin\debug so the reference of the mainproject will now find the correct version, and now my breakpoint is being hit again.

This took my weeks to figure out

score 0 · Answer 63 · answered Jun 22 '23 at 21:34

0

In my case using VSCode my launch.json was pointing to net6.0 and I upgraded to 7 so all new builds were not in the same folder.

answered Jun 22 '23 at 21:34

Steji

580
1
6
17

score -1 · Answer 64 · answered Oct 08 '14 at 07:27

-1

In my case I forgot to include the "stdafx.h" in the header file where I was declaring a template function.

answered Oct 08 '14 at 07:27

mrcointreau

342
5
16

score -2 · Answer 65 · edited Aug 14 '13 at 17:41

I suffered from this recently, and in my case I traced the problem back to something I was doing when testing: changing the system time. I'm not suggesting this is the case for everyone, but thought I'd mention it since it hasn't been mentioned already. It appears if you start moving the clock around between debug builds then it can get very confused about what order various files have been created it - I can only assume it is using file modified dates to determine if the source code is valid or not, and which binaries it needs to recompile.

It is also an option to re-save web.config to bump its modification time.

score -3 · Answer 66 · answered Jul 13 '16 at 07:30

-3

Me just restarted computer and it worked greatly for me.

answered Jul 13 '16 at 07:30

Anjan Kant

4,090
41
39

score -7 · Answer 67 · answered Aug 25 '14 at 04:59

-7

code causing the "The source code is different" error

I found the error occurred when a breakpoint is on a line that can't be broken on. I didn't show the tool-tip in effort to show the line directly after does not have that error.

answered Aug 25 '14 at 04:59

aaaaaa

1,233
13
24

"The breakpoint will not currently be hit. The source code is different from the original version." What does this mean?

67 Answers67

Linked

Related