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'?
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 FilesC:\windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET
FilesI 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.
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:
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.
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.
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.
The problem is that your debug info is not in sync with your assembly. The solution is simple:
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)
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
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".
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.
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.
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.
I encountered this as well. The conditions that caused my issue:
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.
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.
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.
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
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..
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.
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.
