Visual Studio 2015 RTM - Debugging not working

Question

I have installed VS 2015 RTM (nothing else) and I\'m unable to debug any solution, not matter if it\'s an existing one or a brand new one (created with VS 2015 and compiled

Answer 1

In my case it was due to the project Target platforms were different.

Consider : ProjectA (Entry) --> ProjectB

ProjectA's platform in properties was set to x64. And ProjectB's platform was 'AnyCPU'.

So after setting ProjectB's target platform to x64 this issue got fixed.

Note: It's just that Target Platform has to be in sync be it x64 or 'Any CPU'

Answer 2

I was having this same problem with VS2015. I reset the settings, as suggested but still had trouble.

What I had to do to fix it was check "Use Managed Compatibility Mode" and "Use Native Compatibility Mode". Not sure which of those 2 is necessary but checking both and I no longer get the Break Mode issue.

Answer 3

Uhg. I hit the bottom of this page so I started ripping apart my project. I found a solution for my particular problem.

My Issue: I couldn't hit the break-point inside a threaded process. Nothing fancy, I'm just starting a new thread in a console app and the debugger wasn't stopping on the break points. I noticed the thread was being created but it was getting hung up in .Net Framework external calls and specifically the ThreadStart_Context. That explains why my breakpoints never got hit because the .Net Framework is getting hung up something.

The Problem: I found that I could solve this by changing my startup code. For whatever reason, I had a program.cs file that contained Main() and was inside the Program class as you would expect for a console app. Inside Main(), I was instantiating another class via this code;

new SecondClass();

This normally works fine and I have a bunch of other projects with Threaded calls where it works fine (well, I haven't debugged them for some time so perhaps a service pack came along and is causing this regression).

The Solution: Move Main() into my SecondClass and instead of invoking the SecondClass constructor via 'new SecondClass()', update the SecondClass constructor to be a standard static method and then call it from Main. After making those changes, I am able to debug the thread once again.

Hope this helps.

Answer 4

I had this problem after deinstallation of RemObjects Elements 8.3 Trial version. Reinstall Elements 8.3 is a quick bugfix.

Answer 5

I had this issue, and none of the (myriad of) posts on here helped. Most people point towards settings, or options, turning on Debug mode, etc. All of this I had in place already (I knew it wasn't that as this was working fine yesterday).

For me it turned out to be a referencing issue, a combination of DLLs that were included were to blame. I can't say exactly what the issue was, but I have a couple of classes that extended base classes from another project, an implemented interface that itself extends from another interface, etc.

The acid test was to create a new class (in my case, a Unit Test) within the same project as the one failing to Debug, then create an empty method and set a breakpoint on it. This worked, which further validated the fact my settings/options/etc were good. I then copied in the body of the method that failed to Debug, and sure enough the new method starts failing too.

In the end I removed all references, and commented out all the lines in my method. Adding them back in one by one, checking Debug at each step, until I found the culprit. I obviously had a rogue reference in there somewhere...

Answer 6

I had this same issue. In my case, the dll I was trying to debug was installed in the GAC. If your debugging breakpoint hits when you aren't referencing any object in the target assembly, but doesn't when you reference the assembly, this may be the case for you.