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

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'?

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!

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.

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.

Did you ever do this?

https://stackoverflow.com/questions/596142/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

Go to

• Tools
  • Options
    • Debugging
      • General

Uncheck Require source files to exactly match the original version

Select Debug in Solution Configurations, instead of Release

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.

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.

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.

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

I just reloaded, clean and rebuilt works for me.

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".

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

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

1. Go to your bin folder
2. Remove the .pdb files
3. 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)

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

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.

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.

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.

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.

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

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

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

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

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

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

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..

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.

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.

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.

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!

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

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.

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.

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

Note that breakpoints will be lost after doing steps below.

1. Right clicked on the class file
2. Selected Exclude From Project
3. Right clicked on the project
4. Chose Add and Existing File
5. Navigated to pick the class file in question

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.

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

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.

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.

go to:

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

Maybe the dlls are being loaded from GAC.

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

gacutil -u YourDll

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!

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.

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.

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.

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

I did the below for a similar issue:

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

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

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

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.

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).

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)

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)

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

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.

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"/>-->

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

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.

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.

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

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.

Me just restarted computer and it worked greatly for me.

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.