By now you will have heard the exciting news, but if you haven't please first read all about .NET Native Developer Preview.
With the preview you also get debugging support. That means that when you switch to compile your .NET code with the native tool chain, under the covers you have also switched to a new debug engine for .NET Native. With this new debug engine 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 and Parallel Watch windows, Process Lifecycle Management for Store apps (background tasks, suspend, resume, suspend and shutdown), triggering prefetch.
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 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)”):
However, just like the runtime, debugging support is also in Preview, meaning it is not fully functional even with the long list of supported features. So here are some features that we have not implemented, and may do so in the future based on feedback:
- Debugging dumps (with the new .NET Native engine, rather than with the C++ native engine)
- 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 full stepping support
Please try debugging your .NET Native code and let us know if you find anything not working that is not on the list above. If you find issues in debugging that you feel are blocking your experimentation, there is always the workaround of switching back to the purely managed tool chain version of your code and debugging your issue there (which uses the existing debug engine for managed code) – then when you are done diagnosing your issue using the full debugger feature set, you can switch back to native compilation.
Lastly, please do report issues to us by following the instructions at the original post announcing .NET Native.