Visual Studio 2015 project no longer runs in debug mode

This is what I get even when I run in the Debug configuration:

The way I got this to show was by enabling "Just My Code" and warn if there isn't any user code on launch. This is something that recently happened to our project, and I'm not sure what we did to cause this. But I've been unable to fix it. Breakpoints won't fire and quick watch gives weird results.

I've tried googling the issue, but none of the standard "break points won't fire" solutions have worked. I'm all out of ideas.

I've checked the configuration manager and every project is also set to Debug there as well.

I turned off "Enable Optimaizations", and I no longer get the "you are debugging a Release build" dialog. It runs and stops on breakpoints again! However the output window displays this at start up:

> Symbols for the module 'Navigo.exe' were not loaded. > > 1. Use a debug build configuration or disable the debug option 'Enable Just My Code'. > 2. Check the 'Symbols' settings under debugging options.

So this solves my primary problem of no longer being able to use breakpoints and the popup. Which is odd since I thought you needed symbols to be loaded for breakpoints to work. So how can the breakpoints work if the symbols aren't loaded? Maybe it's just a bad message?

Use the Configuration Manager to check what the actual settings are for the Debug configuration - it's at menu Build → Configuration Manager... - in case they are set to use Release:

Also, make sure the project is defining DEBUG correctly, and that "Optimize Code" is not checked:

This has happened to me on a couple of projects too. I reviewed my build settings, as suggested by stuartd. However, 'Optimize code' was not enabled in my build settings. So I enabled it and saved the project. Then I unchecked it and saved again. Problem solved.

There's some kind of bug that causes the --optimize+ flag to be passed to the debugger. Enabling it and then disabling it is an easy workaround until the bug is fixed.

This started happening to me after applying Update 1. Existing projects started showing this, and I can replicate it with a brand new project. All configuration is set to DEBUG, and Optimize is not checked.

The kicker is, running the project the first time (or after a Clean) runs just fine, without any message. Stopping, then re-running the project (note - the project is not rebuiblt) will display the dialog.

The only solution is to turn off the Just My Code option - which seems a hack, as it was on previous to Update 1 without any problems.

If none of mentioned solutions has helped, check your project's AssemblyInfo.cs for explicit DebuggableAttribute application. It seems like it overrides compiler's debug/release options.

I had this line in the file in my case (legacy project, no idea how it got there). Deleting it solved the problem:

[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]

Select menu Debug → Options and unselect the Suppress JIT optimization option. It works for me.

Source: https://connect.microsoft.com/VisualStudio/feedback/details/2116788/flag-optimize-is-passed-to-the-debugger-even-while-the-build-settings-optimize-code-is-not-enabled-on-mvc-c-web-projects-when-using-just-my-code

I encountered this issue as well. The fix that worked for was to simply clean (Build > Clean Solution) and rebuild (Build > Rebuild Solution) my projects.

None of the previous answers worked for me. Restarting IIS fixed it.

Just adding a side note to stuartd's answer:

Be sure you check any dependent projects for the same build settings. You will get the same message prompt if your main project has the proper settings, but your dependent projects do not. It makes obvious sense in hindsight, but it wasn't the first thing to come to mind.

In my case the problem was that the IIS Project URL in my ASP.NET project properties web tab was set to the wrong URL.

It was pointing to http://localhost which I was using with a different copy of the project. The address for the solution I had open was actually configured on my local IIS as http://localhost:90.

Changing to the correct address fixed the problem.

I had the same issue... No matter what I did - nothing worked.

It was an new empty project that was the problem. I ended up removing the project and adding a new project - the new project had to have another name; if I used the same name the error just reappeared - even after a reboot, clean and rebuild... It must be a bug in Visual Studio 2015.

For me, it was a NuGet reference from a private NuGet server. I don't know how it was compiled, but changing the reference to a project reference got me past the problem.

I tried pretty much everything in this list, but in the end I fixed this by opening the solution properties and switching from "Multiple startup projects" to "Single startup project" and back again.

1. Right-click on the solution and choose "Properties"
2. Under "Common properties" change the selection "Multiple startup projects" to "Single startup project"
3. Click OK
4. Run debugging
5. End debugging and repeat steps 1-3, but switch back to "Multiple startup projects"
6. Run debugging again with multiple projects

I've opened my Visual Studio 2012 Pro project in Visual Studio 2015 Express and had the same issue.

I checked my Solution properties → Configuration Properties, and discovered a project was set to Release & x86.

I changed it back to Debug and Any CPU, and the prompt has gone.

In my case, I was developing a VSTO plugin for Outlook, and Outlook was accidentally loading the Release version of the DLL file that I recently installed while testing my installer.

It looks like Visual Studio was trying to use that DLL instead of the Debug one I expected. Fixing which DLL file is being loaded by Outlook fixed this for me.

I met the same problem, and finally I solved it by choosing "Disable Just My Code and Continue".

Just My Code Setting

Resolution steps:

• Go to the Build settings of the offending project's Properties page.

• Scroll right down to the “Advanced...” button.

• Make sure “Debug Info:” is not set to “none”.

  I recommend you to use the full option.

After viewing the link by Patrick as a comment to the question, someone noted a workaround which was to stop the site in IIS Express. I was able to prevent this same problem from arising by doing just that after stopping the debugger in Visual Studio.

However, I was looking into it more, and I believe it could also be related to the 'Edit and Continue' setting for the debugger. When I disabled that in the menu Tools → Options... of Visual Studio, I no longer had the problem. But then that would prevent you from using the Edit and Continue feature, so I am not sure if that's worth it to you.

Menu Tools → Options → Debugger → Edit and Continue (scroll to the bottom of the General list) → uncheck the Edit and Continue checkbox.

I also experienced this suddenly after installing Update 1, but it could just be that I had this setting off in the first place...I am not sure though.

Copying my other answer from here.

As mentioned by @romanoza, Microsoft has updated the bug report with the following information:

> Uncheck the setting Debug -> Options -> Suppress JIT optimization on module load (Managed only)

This is the workaround. They go on to say later:

> We recommend folks leaving it unchecked as having it unchecked will improve both performance and the behavior of just my code in specific scenarios.

Lastly, the acknowledgement:

> It is a bug that it doesn't work with that setting enabled and we're working on a fix for that situation in case some customers still want to debug with that setting turned on.

In case you just need to keep going without any further delays, select the last option from the popup and all will run the same as before.

This was a weird alert.

Rebuilding the Solution won't necessarily clear all the DLL files (especially ones copied from dependent projects).

However, rebuilding the dependency project made this alert go away.

I faced this with Visual Studio 2015 Update 3.

My solution was a little different from all the others and is a bit unique.

I'm working with a website that contains a mix of managed code and ASP Classic, both referencing the same assembly. Visual Studio was complaining that my managed DLL file was a release build.

The issue was an uncaught exception in my assembly, but it was being thrown by a ASP Classic page via interop. Visual Studio wasn't able to handle debugging this and displayed the error message. The same exception thrown from managed code would have brought up the debugger as expected.

Correcting the issue in my managed assembly's constructor fixed everything.

It all makes sense now that I look back at the big picture, but at the time, the error message led me down a very deep path, and I tried everything in the answer here until I had that "Ah-ha!" moment.

I spent two days, and it looks like Reset the Visual Studio 2017 Experimental Instance helped me.

I'm using VS 2019 v16.10.4 and just ran into this. The "Check Optimize Code option -- Save -- Uncheck Optimize Code option -- Save" in the project options Build screen routine worked but ONLY after restarting VS.

Side-note: Amazing - this was asked 5 years, 11 months ago but it is still not fixed ...