Develop Reference

Visual Studio 2015: I can't debug and use breakpoints in Release mode

I have developed an UWP app that uses a lot of NuGet packages (MvvmLight, SQLite, ...) and other resources (Syncfusion controls).
I encounter a bug with the Store app, which is already published for tests, that is not present when I build the app in "Debug" mode.
So, I've tried to debug in "Release" mode, with the checked options "Compile with .NET Native tool chain" and "Optimize code". The build ends successfully, but I encounter an exception with a Syncfusion control (SfDataGrid) on the main page of the app. I would like use breakpoints to understand what happens, but they are deactivated as I build the app in "Release" mode.
If I build the app in "Debug" mode, with the same options checked ("Compile with .NET Native tool chain" and "Optimize code"), I don't encounter the same bug with the Syncfusion control, and the defined breakpoints are well keeped.
So I don't see how I could fix my problem:
if I create a new solution and built it in "Release" mode, the breakpoints are well keeped, and I can debug the code
if I build Syncfusion samples in "Release" mode, it's the same thing: the breakpoints are well keeped, and I can debug the code
I have compared the "build" parameters of the app and the other ones: they are the same
I have also looked at the "Just-in-Time" page, in the Visual Studio "options". I've got the following error: "Another debugger has registered itself as the Just-In-Time debugger. To repair, enable Just-In-Time debugging or run Visual Studio repair.". Ive tried to "repair" Visual Studio, but it's always the same thing...
Here is the "Options" settings:
And the result in solution, where breakpoints are disabled:
Would you have any explanation? How could I do to debug my app in "Release" mode?
[Edit 1]: add some details after further investigations
My app is based on a "template" like Template10, called Nentang. The structure of the project is the same, and they share a big part of references or NuGets packages.
But if I compare the build result of the "blank" Nentang and my solution, there are some differences that I don't understand:
as explained, on my app, the breakpoints and debug don't work in "Release" mode, and I can see that almost all modules don't have any "Symbol File":
=> only "ntdll.dll" and "KernelBase.dll" are linked to thier pdb file in a local directory: "C:\Users\myname\AppData\Local\Temp\SymbolCache"
on the "blank" Nentang app, the breakpoints and debug work well in "Release" mode, and I can see that almost all modules have a "Symbol File":
=> allmost half of the modules are linked to the same file in the "project" directory: "C:\Projects\Samples...\Nentang.UWP\bin\x64\Release\AppX\Nentang.UWP.pdb"
=> another quarter of the modules are linked to the same file of a "system" directory: "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.NET.Native.Framework.1.3\1.3\x64\ret\Native\SharedLibrary.pdb"
=> the other modules are not linked to a Symbol File: it's the case of "ntdll.dll" and "KernelBase.dll"
How could I restore the "Symbol files" of my project?
I have also remarked a "strange" parameter in the properties of my solution, that is not present is the Nentang properties:
There is this parameter: "f:\dd\ndp\fxcore\CoreRT\src\System.Private.CoreLib\src\System\Runtime\ExceptionServices\ExceptionDispatchInfo.cs"
What does it mean? Could it explain my problem?

Debugging optimized code is always a challenge - even more so with .NETNative. Here are a few things you could try:
Disable Just My Code
Suppress JIT Optimizations: This will not help for modules built with .NETNative toolchain. If the exception occurs in Release builds without .NETNative, then check the debugger option called "Suppress JIT optimization on module load (Managed Only)". As the name implies, this will cause the CLR to JIT compile code unoptimized, which will allow you to set breakpoints and inspect locals.
Look at the Output window for clues as to what went wrong. The exception message will be there and the preceding messages may help diagnose the cause.
Debug your application with Native debug engine. You can do this by checking the Native checkbox under the Debug tab of the project properties.
Last resort is to debug the assembly.

Visual Studio 2012 "Step into" wrong function and Breakpoints not hit

I'm working on a Xamarin project and when I make an instance of a certain class a bearkpoint inside the constructor never gets hit. Just after instancing the class i call for a function of that class and the Step Into functionality of visual studio 2012 sends me to another totally unrelated function of another class.
When I comment that unrelated function that the Step Into sends me to and call the function again, the Step Into sends me again to a totally unrelated function of another third class.
The functions don't even have the same name.
I already cleaned, rebuild, manuallly deleted bin and obj and nothing works.
Any one knows what is happening?
Note: the Go To Definition (F12) command works as expected but the Step Into (F11) doesn't. I also have it on Debug mode instead of Release.

Well the problem here is obviously your debug symbols are out of sync with your source files. A few ways this can happen:
you're not actively building debug symbols (thus relying on older leftovers), or have optimizations enabled. Note that simply having the debug configuration selected doesn't mean this is not the case -- "debug" is just a label, you can name it puppies for all VS cares. Check the settings.
it's possible there's conflicts with the GAC or the symbol server trying to download wrong symbols. Check your file names that they're not too similar to system DLLs.
You mentioned Xamarin -- I'd triple check that it has the right symbols. It's possible following the call stack through out of date Xamarin symbols is screwing up things when it comes out and back into your code (events).
Another thing I'd try is to cold start your executable, then attach through VS. Go line by line in the Output window and see which symbols are loaded, and equally important, which are failing to load. Check your output folder, check the .pdb file names. Make sure you're not confusing things with the .vshost.exe file, you only care about the executable and any DLLs of your own.

Can't debug Outlook add-in project

I have a problem in Outlook 2010 add-in project, After first debugging for the project I can't debug it one more, it show me the following warning :
The following module was built with optimizations enabled or without debug information:
{Path to DLL}
To debug this module, change its project build configuration to Debug mode. To suppress this message, disable the 'Warn if no user code on launch' debugger option.
and it didn't take any change I have made.

To debug, you need debug symbols and non-optimized code - make sure you have Debug symbols enabled for your build configuration, i.e. Define DEBUG constant checked and optimizations disabled, i.e. Optimize code unchecked.

Visual Studio Breakpoint Warning

When debugging my code, I often throw breakpoints in to check the values of local variables to make sure everything is on the right track.
Lately, when I make changes to my code and recompile, all my breakpoints turn into the outline of a circle (instead of a full red circle) and it gives me an error that reads;
The breakpoint will not currently be hit. No executable code is
associated with this line. Possible causes include: conditional
compilation or complier optimizations.
What's strange about this issue is that I can simply remove and add the breakpoint and everything will work completely fine.
I am not using any type of conditional compilation or complier optimizations. Does anyone know what this means or how to fix this? It gets quite annoying replacing 10-12 breakpoints each time I compile.

This can happen for a few reasons
The code the debugger is using is different from the code that the application is running
The pdb file that the debugger is using is different from the code that the application is running
The code the application is running has been optimized and debug information has been stripped out.
The code in which you have breakpoints on hasn't been loaded into the process yet (assuming the things above are not the culprits)
If you are attaching the debugger, pay attention to what .net framework it's attaching to (i've had issues with it using .net 4 when code was all .net 2.0)
The assembly you have is also in the GAC. This might happen if say you installed your program so you could debug it, but the installer put the dll in the GAC.
Remove the reference and re-add it (thanks to forsvarir). Typically this occurs when the project that is referenced is not in the solution, and VS will copy the dll from the bin directory of another project. You will know this was the issue when you try to re-add the reference, and can't find the project :)
It's pretty tough to figure out what's going on here, but i would suggest using the fusion log viewer to see what is being loaded and where it's being loaded from and then you can look at the dll and see if it's old code, etc.

Check the project settings
Make sure you don't check the code optimize option, and make sure debug symbols are checked.
Notice that when you change the configuration other settings might change as well and you might not see. Make sure the values are correct for the configuration you are attempting to compile.
Delete the output files
Physically delete all generated DLLs, PDBs and EXEs. Then compile again to generate the files. Sometimes Visual Studio can "get lost" and "forget" to overwrite the output files when you build your solution.
Restart your computer
It usually solves 99% of problems. I already had some issues with Visual Studio and restarting it or the computer solved the problem.

I know this is an old post but still timely enough as I was looking for any other reason I might be getting this problem.
That being said you also might want to check the "Temporary ASP.NET Files" in your c:\Windows\Microsoft.NET\[Frameworks] directories if you are creating a web application as these files are often the cause in my experience.

The use of the precompiler directive #line appears to affect the breakpoints behavior as well, as I've just discovered.

Adding this response to the old thread in case someone like me is tracking down this mystery in an older ASP.Net application. I had one Webform code-behind which did not respond to breakpoints with the "...no executable code..." debugger warning. It was doing my head in as all of the other pages were working fine. I'd done the clean, rebuild, purged the temporary ASP.Net files, no joy.
The culprit with this file was the inclusion of several #ExternalSource directives surrounding some of the member variable declarations. Once those were removed and the project rebuilt, the break point behavior was restored. Those ExternalSource lines were appearing in the generated section of the code-behind. Not sure why they were there.

Enable and disable "Step into" debugging on certain project in a Visual Studio solution

I have a Visual Studio solution with four C# projects in it. I want to step into the code of a supporting project in the solution from my main project, but when I use the "Step into" key, it just skips over the call into that other project. I've set breakpoints in the supporting project, and they're ignored, and I can't for the life of me get it to step into any references to that project.
Everything is set to compile as "Debug", and I've seen Visual Studio warn me that my breakpoints won't be hit before - it doesn't do that in this case. It's as though it looks as though my code will debug, but then at run-time, there's a setting somewhere that tells Visual Studio not to step through the code in that project. All the other projects in my solutions debug without problems.
What box have I checked to cause this behavior?
UPDATE FOR CLARITY: The "Just my code" option is currently disabled. Also, since the code belongs to a project in my same solution, I don't think the "Just my code" option applies here. I thought it only applied to pre-compiled code that I didn't have the source for, but since I have the source in my project, I don't think this option has any effect.

Not sure if this is it, but "Tools>Options>Debugging>General:Enable Just My Code" is a possibility. (I prefer to always leave this unchecked.)

It turns out that the assembly needed to be copied into the GAC before it could be debugged. Under the debugging option "Just my code", there's an option to suppress an error if you don't have any user code, and it was suppressing the following error:
The Following mobile was built either
with optimizations enabled or without
debug information. (Module name and
path) To debug this module, change its
build configuration to Debug mode.
Since I was building it in Debug configuration, I searched on that error message and got this:
http://claytonj.wordpress.com/2008/01/04/the-following-module-was-built-either-with-optimizations-enabled-or-without-debug-information/
Problem solved. I don't know why it needs to be in the GAC in order for me to step into the project, but it does. I don't ask why, I just ask how, and then I do it...

One thing to check for is that your supporting project assembly has not been installed in the GAC. Open a command prompt and run the following to make sure...
gacutil /l assemblyName

You need to ensure the supporting projects have pdb files or else Visual Studio will not have the necessary information to step through the code.

If you have the source code for the dll's into which you are trying to step into, do the following:
Click on the project in which these dll's are added as reference and remove them.
Add the Project(s) corresponding to the dll(s) to the solution
Right click on the project -> Add Reference -> Choose the newly added Project(s).
Now set the break point and debug the code.. You will be able to step into the code.
The reason for the issue is because you program is still referencing the old dll (without the source code) as it has been added to your project as a reference. Once you remove that dll and add the Project (Source code of the dll) of the dll, Visual studio will be able to step into your code.

A couple of possibilities:
There is a check box to step into "just my code". Its intent is to make it so you can't step into Microsoft's Framework code (unless you choose to by unchecking the box).
You might try recompiling the supporting code to make sure the code you're debugging exactly matches the code file you're looking at. VS does care about this and will disable a breakpoint if you put it in the code file whose version doesn't match. Also, make sure the PDB file is in the same directory as the DLL.

In Visual Studio 2013 one way to cause this behaviour is to set build configuration to Release.
Put it back to Debug and see if that helps.