Bit of a strange and very annoying problem.
I’m using Visual Studio 2010 for an ASP.NET webforms project. I was able to set breakpoints in an activex control, load the page and then attach the Visual Studio debugger to the Internet Explorer process running (shows up as Type ‘Script, T-SQL, Managed) then reload the page and my breakpoints would be hit.
However, after several small subtle changes (and lots of tidy-up changes), when I do the same thing, my breakpoints are not hit. The breakpoints look okay – the main change is when I look at the Debug > Windows > Modules screen, there are now no references to the iexplore process, even though the debugger is still connected to it.
I’m a bit reluctant to undo all my changes but I suspect that it might be down to ip addresses. Most of the code should run as an ipv4 address but I suspect that the Visual Studio debugger is running with ipv6 address.
Has anyone come across this type of issue, where ip address versions are messing up debugging processes?
Okay, found the solution to this after a week! It was nothing to do with IP addreses. The ActiveX component was limited to .NET 3.5.0 and so when it was loaded by IE, it ran in .NET 2.0. The rest of the project was .NET 4.0 and when Visual Studio was debugging it automatically debugged code type ‘Automatic: Native’ which defaulted to .NET 4.0. Although I could attach to the IE process and all the breakpoints looked ok (solid circles), none of them were hit because no symbols were loaded. Clicking the ‘Select’ button when attaching to the IE process, allowed me to choose Managed(v2.0, v1.1, v1.0) code and the breakpoints were hit. You can’t debug both .NET 4.0 and .NET 2.0, but you can use two seperate instances of Visual Studio to debug your complete project.
Hope this helps anyone else who trips over this one like I did.