Debugging support for .NET Native Preview apps

Debugging support for .NET Native Preview apps

Rate This
  • Comments 4

this post has been updated to reflect debugging support available in Visual Studio 2013 Update 3

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 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)”):

clip_image002

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:

  1. Set Next Statement
  2. Editing values in the variable windows
  3. Tasks window (incl. the new async support)
  4. Async debugging support in the Call Stack window
  5. Support for Return Values
  6. Edit and Continue
  7. 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.

Leave a Comment
  • Please add 5 and 2 and type the answer here:
  • Post
  • LET US KNOW WHEN YOU WILL BE SUPPORTING VB.NET FOR .NET NATIVE AND WE WILL START USING NATIVE AND DEBUGGING IN NATIVE.

  • You mentioned "a new debugging engine". Does that mean .NET Native debugging won't be using CorDebug? Will CorDebug be enhanced or is there a new API replacing it? If there's a new API will it be public? I'm using CorDebug to inspect dumps so keen to know what it's future is :-)

  • @THIS IS NONSENSE: Thank you for the feedback. VB.NET is definitely on our radar. We've started with C# but we intend to bring up VB.NET as well.

    @Greg: .Net Native will still use ICorDebug for managed debugging.  However, .Net Native has a new engine under the hood driving it which has some behavioral differences from the CLR's implementation of ICorDebug.  

    In general, your CorDebug dump inspection tool will work on .Net Native apps but it will need some modifications to work on the new runtime. The ICorDebug API surface will look very familiar to anyone who's written inspection tools but there will be some porting as it isn't identical.

    We need to document exactly what you'll need to modify in your debugger to support .Net Native. We haven't done that for the preview release but we intend to document the API.

  • Awesome, thanks for the feedback Andrew! Looking forward to trying it out.

Page 1 of 1 (4 items)