We found a "work around" to this issue. It doesn't solve it, but it does allow the developer on our team that's having this issue to be able to debug the project now.
https://stackoverflow.com/a/19787785/323696
Manually attaching the process (TOOLS -> Attach to process (ctrl + ALT
+p)) to w3wp.exe for IIS, or IIsExpress.exe also worked, which leads me to suspect that VS is having trouble figuring out which process it
should attach to automatically.
On the developer's computer, with other projects and solutions, when trying to debug, Visual Studio automatically attaches to the w3wp.exe process.
However, on the one solution/project that he's having issues with, and also only on his computer, he is having to manually attach to the w3wp.exe process every time he uses the Visual Studio debugger.
EDIT 08/12/2015:
The actual solution to the issue on the developer's computer was that in IIS, at the server-level, in the "HTTP Response Headers" properties, there was a duplicate entry for the "X-Powered-By" HTTP header.
Once that duplicate entry was removed, there were no further issues with starting the debugger in Visual Studio.
What led us to check the "HTTP Response Headers" properties was this SO post: https://stackoverflow.com/a/6124267/323696.
It suggested to check that the "HTTP Keep Alives" were enabled, something that gets checked in the "HTTP Response Headers" properties in IIS, right-clicking on a HTTP header, then selecting "Set Common Headers...", then checking the "Enable HTTP keep-alive" option in the "Set Common HTTP Response Headers" dialog pop-up.
While the "Enable HTTP keep-alive" setting was already selected, and wasn't the root cause or our issue, following that lead to check that setting was what led us to find the root cause, the duplicate HTTP Response Header.
Problem Solved, but the symptoms didn't give any indication to what was causing the issue. While we lost a day of work to that issue, it feels good to to done with it and be able to move on now.
