This post has been updated to reflect debugging support available in Visual Studio 2015
By now you will heard about .NET Native, but if not read about it first.
With a new tool chain and runtime you also have a debug engine designed to debug .NET Native binaries. That means that when you switch to compile your .NET code with the .NET Native tool chain, under the covers you have also switched to the debug engine for .NET Native. The debugging experience you get includes (but certainly is not limited to):
F5, Attach, Output window, Exceptions, Breakpoints, Step Into/Over/Out, Run To Cursor, Call Stack, Data and Variable windows, Just My Code (filtering stacks, exceptions, and private fields in variable inspection), Modules window, Address level debugging (Disassembly, Memory, Registers windows), Threads window, Parallel Stacks Parallel Watch windows, Process Lifecycle Management for Store apps (background tasks, suspend, resume, suspend and shutdown), triggering prefetch, and debugging dump files.
In addition to bringing that level of parity, with .NET Native you also get very cool interop debugging between your managed and native code on ARM (something only possible on x86 and x64 for your regular .NET apps).
So have fun debugging, and you’ll know you are using the new debug engine for .NET Native when you see in the Processes window under the Debugging column the name of the new engine “Managed (Native compilation)” (in contrast with what you’d see when you debug your other .NET apps “Managed (v4.5, v4.0)”):
It is also important to note that there are some features that we have not implemented yet (let us know which ones are impactful to you):
- Set Next Statement
- Editing values in the variable windows
- Tasks window (incl. the new async support)
- Async debugging support in the Call Stack window
- Support for Return Values
- Edit and Continue
- Just My Code — works correctly for showing call stacks but is not supported when stepping