{"id":44897,"date":"2015-07-29T10:55:00","date_gmt":"2015-07-29T10:55:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/visualstudioalm\/2015\/07\/29\/debugging-net-native-windows-universal-apps\/"},"modified":"2022-08-03T00:26:15","modified_gmt":"2022-08-03T08:26:15","slug":"debugging-net-native-windows-universal-apps","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/devops\/debugging-net-native-windows-universal-apps\/","title":{"rendered":"Debugging .NET Native Windows Universal Apps"},"content":{"rendered":"

With the release of Windows 10 we also shipped Visual Studio Tools for Windows 10<\/a>. As you will have heard Universal Windows apps written in .NET (either C# or VB) will be compiled to native machine code before being deployed to customer devices using .NET Native<\/a>. However, the default Debug configuration still uses .NET Core runtime<\/a> to allow for a fast edit->compile->debug cycle. You always need to test with the actual code generation and runtime technology your application will use when running in production as it can expose bugs you might not be able to find with your development configuration (e.g. race conditions that manifest due to different performance characteristics). To facilitate this, when you choose the Release build configuration your app is compiled using the .NET Native tool chain.<\/p>\n

If you don\u2019t find any issues with the .NET Native build of your application, great! However if do you run into any issues that require you to debug there are a few things to note:<\/p>\n

    \n
  1. When you are debugging an app built with the .NET Native tool chain you will be using the .NET Native debug engine which has some capability differences from normal .NET debugging<\/a><\/li>\n
  2. The Release configuration will be using code optimizations that will impact debugging<\/li>\n
  3. Variable inspection of runtime types will be slightly different<\/li>\n<\/ol>\n

    Code optimizations<\/h2>\n

    If you run into an issue when testing the Release configuration that you need to debug it is important to note that the Release configuration is by default fully optimized code (e.g. code inlining<\/a>\u00a0will be applied in many places). These optimizations will have a significant impact on the debugging experience including unpredictable stepping and breakpoint behavior (due to code inlining) and the inability to inspect most variables due to memory optimizations.<\/p>\n

    This means you will want to debug a non-optimized .NET Native build. This fastest way to do this is simply to disable optimizations (covered below), however we recommend creating a new build configuration so your existing Debug and Release configurations continue to work the way you expect. To do this open the \u201cConfiguration Manager\u201d from the build configuration dropdown.<\/p>\n

    \"clip_image001\"<\/p>\n

    Then from the \u201cActive solution configuration\u201d dropdown choose \u201c<New\u2026>\u201d<\/p>\n

    \"clip_image002\"<\/p>\n

    Give it a name you will understand (e.g. \u201cDebug .NET Native\u201d) and choose \u201cCopy settings from Release\u201d and click \u201cOK\u201d<\/p>\n

    \"clip_image003\"<\/p>\n

    Open the project\u2019s property page, and on the build tab uncheck \u201cOptimize code\u201d<\/p>\n

    \"clip_image005\"<\/p>\n

    You now have a build configuration you can easily switch to for debugging .NET Native specific issues. Assuming you can reproduce the issue with the non-optimized build this will yield a much better debugging experience.<\/p>\n

    Inspecting Runtime Types<\/h2>\n

    One thing that will be different from debugging normal JIT based .NET applications is that when inspecting objects from the Windows Runtime (including XAML UI Elements) you will see a \u201c[Native Implementation]\u201d node. In order to inspect the elements properties you will need to look under this node (this is due to the fact that these objects are actually implemented in native code and are accessed via a thin .NET wrapper). When looking at this node, if you did not enable Microsoft Symbol Servers in your symbol settings<\/a> you will see a message saying \u201cinformation not available no symbols loaded for [module name]\u201d. Right click on the \u201c[Native Implementation]\u201d frame and choose \u201cLoad Symbols\u201d, the debugger will then download them from the Microsoft Public Symbol servers.<\/p>\n

    \"clip_image007\"<\/p>\n

    Once symbols are loaded you will be able to inspect the property values from the \u201c[Native Implementation]\u201d node. For example, to see the value of the \u201cText\u201d property on a Textbox object you need to look under the \u201c[Native Implementation]\u201d node\u2014this does mean that if you hover over \u201ctextbox1.Text\u201d in the editor while debugging .NET Native you won\u2019t see a DataTip.<\/p>\n

    \"clip_image009\"<\/p>\n

    Summary<\/h2>\n

    You likely won\u2019t need to spend much time debugging your code compiled with .NET native, but when you do remember to disable code optimizations and that many properties for runtime types will require looking at the \u201c[Native Implementation]\u201d node. As always we want to hear how the debugging experience is working for you, and how we can improve it. So please let me know in the comments section below, through Visual Studio\u2019s Send a Smile tool<\/a>, or via Twitter<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

    With the release of Windows 10 we also shipped Visual Studio Tools for Windows 10. As you will have heard Universal Windows apps written in .NET (either C# or VB) will be compiled to native machine code before being deployed to customer devices using .NET Native. However, the default Debug configuration still uses .NET Core […]<\/p>\n","protected":false},"author":68,"featured_media":45953,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1,225],"tags":[],"class_list":["post-44897","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops","category-git"],"acf":[],"blog_post_summary":"

    With the release of Windows 10 we also shipped Visual Studio Tools for Windows 10. As you will have heard Universal Windows apps written in .NET (either C# or VB) will be compiled to native machine code before being deployed to customer devices using .NET Native. However, the default Debug configuration still uses .NET Core […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/44897","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/comments?post=44897"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/44897\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media\/45953"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media?parent=44897"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/categories?post=44897"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/tags?post=44897"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}