Home .NET .NET Native- what does this mean for developers on the Universal Windows Platform (UWP)?

.NET Native- what does this mean for developers on the Universal Windows Platform (UWP)?

by admin

In Windows 10, Universal Windows applications in managed languages (C#, VB) go through a compile-to-machine code procedure in the store using .NET Native.In this article, we invite you to learn more about how this 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 corresponding article.

What is .NET Native?

NET Native – is a pre-compilation technique used when creating generic Windows applications in Visual Studio2015. The .NET Native tools compile your managed-code IL libraries into native libraries. Every managed (C# or VB) universal Windows application uses this technology. Applications are automatically compiled to native code before they get to the end device. If you want to dive deeper into how this works, we recommend the article " Compiling applications using .NET machine code ".

How will .NET Native affect me and my application?

Specific metrics may vary, but in most cases your application will run faster, run more quickly, and consume fewer system resources.

  • Up to 60% increase in cold start speed
  • Up to 40% increase in hot start speed
  • Reduced memory consumption when compiling to machine code
  • No dependency on desktop .NET Runtime on installation

Since your application is compiled to machine code, you will get a performance gain related to the speed of execution of native code (close to C++ performance). You can still take advantage of the 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: manageable development with near C++ performance. Isn’t it nice?

Differences in compilation settings in debug and release

Compiling in .NET Native is a complex process, usually slower than classic .NET compilation. The advantages mentioned above come with a price in terms of compile time. You can choose to compile natively every time you run an application, but you will spend more time waiting for the build to complete. Visual Studio tools can help you manage this better, smoothing out the development experience as much as possible.
When you build a project and run it in debug mode, you use IL code on top of the CoreCLR packaged in your application. The .NET system assemblies are added to your application code, and your application honors the dependency of the Microsoft.NET.CoreRuntime (CoreCLR) package.
This means you get the best possible development experience: fast compilation and deployment, ample debugging and diagnostic capabilities, and the operability of all the other tools you’re used to when developing in .NET.
When you switch to release mode, by default, your application starts using the .NET Native build chain. Because the package compiles to machine code, it is no longer required that the package contain .NET framework libraries. In addition, the package now depends on a fresh version of the .NET Native environment – unlike the CoreCLR package. The .NET Native runtime environment on your device will always be compatible with your application package.
A local native compilation with a release configuration allows you to test the application in an environment close to what the end user will have. It is important to test in this mode regularly as development progresses.
A good rule of thumb to get into the habit of testing your application in this way during the development process is to make sure that you find and fix problems that might occur as a result of compiling with .NET Native in time. Most of the time there shouldn’t be any problems, however, we are aware of a few things that don’t work well with .NET Native. For example, arrays with a dimension greater than four. After all, your users will get a version of your application compiled through .NET Native, so it’s a good idea to check that everything works up front and before the application is delivered.
In addition to the fact that it’s a good idea to test in native compilation mode, you may also notice that the AnyCPU build configuration is gone. With the advent of .NET Native, the AnyCPU configuration no longer makes sense because native compilation is architecture dependent. An additional consequence of this is that when you package your application, you need to choose all three architecture configurations (x86, x64 and ARM) to be sure that your application will run on as many devices as possible. It is, after all, a universal Windows platform! By default, Visual Studio is configured to build exactly as shown in the screenshot below.
.NET Native- what does this mean for developers on the Universal Windows Platform (UWP)?
All three architectures are selected by default
It’s important to note that you can still build AnyCPU libraries and use the corresponding DLLs in your UWP application. These components will be compiled into binary libraries under the appropriate architectures specified in the project settings.
Finally, the last major change in the familiar 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 run in the cloud. When you create a package for the store in Visual Studio, two packages are created : .appxupload for the store and a "test" .appx for local installation. The .appxupload package contains MSIL builds 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 the application locally.
.NET Native- what does this mean for developers on the Universal Windows Platform (UWP)?
The .appxupload package is sent to the store; the Test folder contains the appx package for local installation
Two consequences of this: firstly, you as a developer no longer have access to the revision number of your app (the fourth number). The store reserves this number as a way to version the application package if for some reason you need to recompile in the cloud. Don’t worry, you can still manage the other three numbers
The second thing you need to keep in mind is that you need to be careful about which package you upload to the store. Since the store does the compilation to machine code for you, you can’t load native assemblies created by the local .NET Native compiler. Visual Studio can help you figure this out so you can choose the right package.
.NET Native- what does this mean for developers on the Universal Windows Platform (UWP)?
Select "Yes" to upload to store
When you use Assistant to create app bundles, you need to select "Yes" in response to Visual Studio asking if you want to create a bundle to upload to the store. I also recommend selecting "Always" for the "Generate app bundle" option, which will create a single .appxupload file, ready for download. Full instructions on how to create bundles for the store are available in the article " Bundling Windows universal apps for Windows 10 ".
As a summary, the main changes in the way you work are from using .NET Native:

  • Regularly test your application in release mode
  • Make sure you leave the package revision number as 0. Visual Studio won’t let you change it, but you shouldn’t do it in other editors either.
  • Only upload .appxuploads to the store, assembled in the process of creating a package for the store, if you upload .appx for a UWP app, you will get an error in the store.

More tips on using .NET Native

If you run into a problem that you suspect is caused by .NET Native, there is a technique that can 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, trying to debug the release configuration will be difficult. Instead, you can create your own configuration by enabling .NET Native compilation in it. Make sure that you do not optimize the code. See 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, through NuGet, you can put in your application Microsoft.NETNative.Analyzer (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 evaluate for yourself the improvements in load 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 which has not gone through a compilation procedure, you will run into a nontrivial problem. It looks something like this :
    • API ExecuteAssembly in uwphost.dll is not supported for this application type. App.exe calls this API.
    • API DllGetActivationFactory 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 create the packages correctly and run WACK on the corresponding package. Follow build recommendations to avoid running into this problem.

    • NET Native applications that use reflection can fail the Windows App Cert Kit (WACK), referring to Windows.Networking.Vpn for a fix. To fix the problem, add the following line to the rd.xml file and rebuild the package :
      < Namespace Name="Windows.Networking.Vpn" Dynamic="Excluded" Serialize="Excluded" Browse="Excluded" Activate="Excluded" />

    To summarize

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

    You may also like