I've got a multi-project solution (legacy code, over a decade old). Most of the projects are .Net 4.0, one or two of them are 3.5. All the code is in C#. It's a web app, with IIS running on my local machine for dev/debugging purposes. Whenever I'm debugging I attach to the w3wp.exe process through the Debug menu in VS. This has been working fine for me throughout the last several months that I've been working on this project- I've been able to place breakpoints wherever I wanted and they worked fine. But it stopped working a couple days ago. Now, as soon as I attach to the w3wp.exe process, all breakpoints turn hollow and I get the "The breakpoint will not currently be hit. A copy of [file] was found in [.dll], but the current source code is different from the version built into [.dll]" message when hovering over the hollow breakpoint.

I've run into this numerous times throughout my career, and I've always been able to fix it through either a clean and rebuild or a machine reboot, or something. But nothing I've tried this time has worked. Here's a list of what I've tried so far:

• Clean/Rebuild solution (numerous times)
• Clean/Rebuild individual projects (numerous times)
• Reboot machine (numerous times)
• iisreset through command prompt (numerous times)
• Remove application in IIS and create new one (numerous times)
• Open solution in alternate versions of Visual Studio and attach to w3wp.exe through them (numerous times)
• Delete all generated .dll's, .pcb's, etc, followed by a clean and rebuild (numerous times)
• Menu> Debug> Options> Debugging> General:
  • Uncheck "Require source files to exactly match the original version"
  • Ok, so this "works", in the sense that the breakpoints return to the normal filled-in state and will be "hit". But this isn't a viable solution for debugging, since Visual Studio is using an alternate version of the code. Any changes I make are essentially ignored by VS studio when debugging this way, and I can't get variable values through mouseover or by adding a watch. In other words, for practical debugging purposes this "solution" is worthless to me.
• One thing that gave me a glimmer of hope:
  • The .cs file that I'm working one was open in Notepad++. I noticed this because one suggestion on Stackoverflow mentioned opening the .cs file in an outside editor, making changes to it, saving the changes, then rebuilding in VS and reopening the file in VS. After doing all this (and making sure the file was no longer open in Notepad++ I attached to w3wp.exe gain and the breakpoints came back to their normal, filled-in functioning state, and all seemed to be as it should... for one build. Then I made more changes and rebuilt the solution, then attached to w3wp.exe and the breakpoints went hollow again, and I haven't been able to return them to their functioning state since. I've opened the file in Notepad++, made changes, saved changes, closed the file in Notepad++, but to no avail.

​

At this point might head is hurting from beating it against the wall. So I've come here hoping someone might be able to suggest the magic bullet that will kill this problem for me. I've any of you have any suggestions, I'm all ears.

​

(Please forgive me If I've violated any of the rules of this sub. This is my first post here. I'll do my best to remedy any problems I've created, or delete the post if need be.)