.NET Native - what does this mean for developers under a universal Windows platform (UWP)?

In Windows 10, universal Windows applications in managed languages ​​(C #, VB) undergo in the store a compilation procedure into native code using .NET Native. In this article, we invite you to learn more about how it works and how it affects the application development process. Below you will find a video interview with a representative of the .NET Native development team and a translation of the relevant article.

What is .NET Native?

.NET Native is a precompile technology used to create generic Windows applications in Visual Studio 2015. The .NET Native tools compile your IL libraries with managed code into native libraries. Each managed (C # or VB) universal Windows application uses this technology. Applications are automatically compiled into the native code before they reach the end device. If you want to dive deeper into how it works, we recommend the article “ Compiling applications using native .NET code ”.

How will .NET Native affect me and my application?

Specific indicators may vary, but in most cases your application will run faster, run faster, and consume less system resources.

• Up to 60% increase in cold start speed
• Up to 40% increase in hot start speed
• Reduced memory consumption when compiled into native code
• No dependency on the .NET Runtime during installation

Since your application is compiled into native code, you will get a performance boost related to the speed of native code execution (close to C ++ performance). In this case, you can still enjoy the benefits of industrial programming languages ​​C # or VB and related tools.
')
You can also continue to use the full power of the software model available in .NET with a wide range of APIs for describing business logic and with built-in memory management and exception handling mechanisms.
In other words, you get the best of both worlds: managed development with performance close to C ++. Isn't that great?

Differences compilation settings in debug and release

Compiling in .NET Native is a complex process, usually slower compared to classic compiling in .NET. The advantages mentioned above have a price in the form of a compile time. You can choose to compile natively each time you launch the application, but you will spend more time waiting for the build to complete. Visual Studio tools can help you better manage this by smoothing out development experience as much as possible.

When you build a project and run in debug mode, you use the IL code on top of CoreCLR, which is packaged in your application. System .NET assemblies are added to the code of your application, and your application considers dependency on the Microsoft .NET.CoreRuntime (CoreCLR) package.
This means that you get the best possible development experience: fast compilation and deployment, extensive debugging and diagnostic capabilities, and the performance of all the other tools you are used to when developing in .NET.

When you switch to release mode, by default, your application starts using the .NET Native build chain. Since the package is compiled into native code, it is no longer required that the package contain the libraries of the .NET framework. In addition, the package now depends on the latest version of the .NET Native environment - unlike the CoreCLR package. The .NET Native runtime on the device will always be compatible with your application package.

Local native compilation with release configuration allows you to test the application in an environment close to what the end user will have. It is important to regularly test in this mode as you develop.

A good rule that you can make a habit of is testing your application this way during the development process to make sure you find and fix problems that can occur as a result of compiling with .NET Native. In most cases, there should be no problems, however, we know a few things that do not work very well with .NET Native. For example, arrays with dimensions greater than four. In the end, your users will get the version of your application compiled via .NET Native, so it’s good to check that everything works in advance and before the application is delivered.

In addition to the fact that it would be nice to test in native compilation mode, you may also notice that the configuration of the AnyCPU assembly has disappeared. With the advent of .NET Native, the AnyCPU configuration no longer makes sense, since native compilation depends on the architecture. An additional consequence of this is that when you package your application, you need to select all three architecture configurations (x86, x64 and ARM) to be sure that your application will run on the maximum number of devices. Still, this is a universal Windows platform! By default, Visual Studio is configured to build in exactly the same way as shown in the screenshot below.


All three architectures are selected by default.

It is important to note that you can still build AnyCPU libraries and use the appropriate DLLs in your UWP application. These components will be compiled into binary libraries under the corresponding architectures specified in the project settings.

Finally, the last significant change in the usual approach as a result of switching to .NET Native is how you create packages for the store. One of the key features of .NET Native is that the compiler can work in the cloud. When you create a package for a store in Visual Studio, two packages are created: .appxupload for the store and a “test” .appx for local installation. The .appxupload package contains MSIL assemblies, as well as explicit references to the .NET Native version used by your application (specified in AppxManifest.xml). This package is then sent to the store and compiled using the same version of the .NET Native compilation chain. Since the compiler is in the cloud, it can be reused to fix bugs without having to recompile applications locally.


Package .appxupload goes to the store; the Test folder contains the appx package for local installation
Two implications of this: first, as a developer, you no longer have access to the revision number of your application (the fourth number). The store reserves this number as a way of versioning the application package if, for any reason, it will be necessary to recompile in the cloud. Don't worry, you can still control three other numbers .

The second thing you need to keep in mind is that you need to be careful about which package you download to the store. Since the store compiles the machine code for you, you cannot load native assemblies created by the local .NET Native compiler. Visual Studio helps you figure this out so that you can choose the right package.


Select “Yes” to upload to the store.

When you use the helper to create application packages, you need to select “Yes” when asked by Visual Studio if you want to create a package to upload to the store. I also recommend choosing “Always” for the “Generate app bundle” option, which will create a single .appxupload file ready for download. Complete instructions for creating packages for the store are available in the article “ Packaging of Universal Windows Applications for Windows 10 ”.

As a summary, the main changes in the way you work, from using .NET Native:

• Test your app regularly in release mode.
• Make sure that you leave the revision number of the package as 0. Visual Studio will not allow you to change it, but you also should not do this in other editors.
• Download only the .appxupload collected during the creation of the package for the store, if you download the .appx for the UWP application, you will receive an error in the store.

More tips on using .NET Native

If you encounter a problem, the reason for which you suspect. NET Native, there is a technique that will help you debug such a problem. The default release configuration optimizes the code so that it loses some of the artifacts used in debugging. As a result, an attempt to debug release configuration will be complicated. Instead, you can create your own configuration by allowing it to use .NET Native compilation. Make sure you are not optimizing the code. Read more about this in the article “ Debugging .NET Native Windows Universal Apps ”.

Now that you know how to debug problems, wouldn't it be even better to learn how to avoid them? To do this, you can put Microsoft.NETNative.Analyzer into your application via NuGet (from the package management console, you can use the “Install-Package Microsoft.NETNative.Analyzer” command). During development, the analyzer will warn you if your code is not compatible with the .NET Native compiler. There is a small subset of the .NET space that is not compatible, but most applications will never encounter such a problem.

If you want to self-assess improvements in download time from switching to .NET Native, you can measure them yourself.

Known problems and solutions

There are a few things to keep in mind when using the Windows Application Certification Kit (WACK) to test your applications:

1. When you run WACK on a UWP application that does not go through the compilation procedure, you will encounter a nontrivial problem. It looks like this:
   
   • API ExecuteAssembly in uwphost.dll is not supported for this application type. App.exe calls this API.
   • DllGetActivationFactory API in uwphost.dll is not supported for this application type. App.exe has an export that forwards to this API.
   • API OpenSemaphore in ap-ms-win-core-synch-11-1-0.dll is not support for this application type. System.Threading.dll calls this API.
   • API CreateSemaphore in api-ms-win-core-kernel32-legacy-11-1-0.dll is not supported for this application type. System.Threading.dll calls this API.
   
   The solution is to make sure that you package correctly and run WACK on the appropriate package. Follow the build recommendations to avoid such a problem.
   
2. .NET Native applications that use reflection may fail in the Windows App Cert Kit (WACK) with a reference to Windows.Networking.Vpn for correction. To solve the problem in the rd.xml file, add the following line and rebuild the package:
   

   < Namespace Name=”Windows.Networking.Vpn” Dynamic=”Excluded” Serialize=”Excluded” Browse=”Excluded” Activate=”Excluded” /> 

Summing up

All Windows users should benefit from using .NET Native. Managed apps from the store will start and run faster. Developers will be able to combine development experiences in .NET in Visual Studio , and users will get a performance boost from machine code. If you want to tell us about your experiences or wishes, use UserVoice . If you want to report an error, please fill in the information on Connect .