The Breakpoint Will Not Currently Be Hit. A Copy Of
Marlys Stotesberry
I have tried cleaning solution, rebuilding , deleting the .pdb files in the obj and bin folders, closing VS and restarting it, restarting the whole machine (It's Windows! Sometimes the most complicated, unexplained problems get fixed like this :\ )
I found the issue, it turns out IIS was configured to use a different copy of the project I had in my backup folder. It sounds pretty silly but I'll keep this question open if someone had something similar.
IIS problem in my case, someone or some migration component changed the Physical Path of my web application (basic settings). Was not pointing to my solution on disk, but to another location with an older version of the app. Restoring the proper path, fixed it.
Check the physical directory the CS file is stored in, there may be two seperate files, and if not open the .csproj in a text editor (not VS). See if the file is referenced twice. If so, just delete one of the lines. If that doesn't work, you could always do what it says and set the breakpoint location :)
Incase someone is having the same issue, go to iis, then application pools on the left then select your application pool then on the right click on View Applications. Now under physical path you will be able to see the physical path to which your virtual path is mapped to, so make sure the physical path is pointing to the right folder and if incase it is not pointing to the right folder then remove your application from the app pool and add it again
Sometimes there are post-build scripts that copy the DLLs from one project to another in order to keep the DLLs updated in different projects. If you modify and compile just one project, then some of these scripts might not be executed and the old DLLs might not be updated.
When I got this problem, I had just started a new solution with an old project. I had not changed the target library in the Project->link->input section. So as soon as I made changes, I got this error. Each solution keeps a copy of the library.
This can happen when you are debugging a .cshtml file with the same name as another file in the project. The debugger picks one of the files as the correct match (seemingly at random), so it will often find a mismatch when it compares the file from the Temporary ASP.NET Files to the source code in your project. The solution in my case was to rename one or both of the files from Standard.cshtml to something more specific.
This is for those who have attempted all of the above approaches and still in search for the solution.I had similar problem, not matter what ever I do, I couldn't hit the break point.Finally, what I realized is the dll I am referring to is not the same one which IIS (root web.config) is using.The dll is installed in the GAC(Global Assembly cache) and that's the reason the debugger never hits and we see this kind of warnings.Follow these steps to resolve it:
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 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.
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!
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.
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.
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.
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 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!
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.
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 ( ) and the mapping for the IIS application was pointing to a disk path that was different to the source code I was working on.
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, 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.
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.
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.
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.
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 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".
(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)
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.
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.
c80f0f1006