. NET Native: compiling. NET applications into native apps

what is. NET Native?
. NET native is a set of precompiled tools for compiling universal windows (UWP) apps in Visual Studio 2015, which compiles managed intermediate language binaries into local binaries, and every managed universal Windows app will benefit from this new technology. The app is automatically compiled into native code before it is installed on the user device. For more information about how it works, you can view MSDN.

what does the. NET native bring?
Depending on the situation, the benefits of. NET native are diverse. In most cases, however,. NET native will make the app start faster, run better, and consume less user system resources. The specific advantages are as follows:

• 60% increased cold start efficiency
• 40% increased thermal start-up efficiency
• Native compile-time application consumes less memory resources
• The system does not need to install desktop. NET Runtime
• Performance can be improved with native code because the application is compiled locally
• Access to industry-leading C # or VB and its programming language tools
• To provide comprehensive and consistent. NET programming model, including the extension APIs required to write business models, built-in memory management, and exception handling

differences in Debug and release two compilation modes
The compilation process of. NET native is complex, compared to traditional. NET compilation, the compilation time is slightly longer. The advantages mentioned above sacrifice part of the compilation time. Visual Studio will remind developers of this when compiling the app, ensuring a good development experience.

When using debug compilation mode, the intermediate language code is running in the app. NET system parts are not packaged with application code, and applications need to rely on Microsoft.NET.CoreRuntime (CoreCLR) packages. This means that developers can enjoy the best development experience. Compiled and configured quickly, with extensive debugging and diagnostic information, all familiar tools can be used in. NET development.

For release mode, the app uses the. NET native tool chain by default. Since the package was compiled into a local binary, it is no longer included. NET Framework library. In addition, the package relies on the newly installed. NET Native runtime instead of the CORECLR package, and the. NET Native runtime on the device is always compatible with the application package.

Native native compilation of release allows the application to be tested in an environment that simulates the user's use. During the application development process, regular testing is important to ensure that the. NET native compiler-related errors are found and modified. In most cases, the. NET native compiler will work, but in a few cases it may not be so smooth, for example, an array of more than 4 dimensions may throw an error. Users end up with a. NET native compiled app, so it's a good idea to test the app's version during the development process, and then release it with no errors.

It is also necessary to add that. NET native cancels the cross-platform compilation mode. Native compiled schemas are independent, so cross-platform compilation is no longer useful. One additional result is that when a developer packs an application, it is necessary to select all three architecture configurations (x86, x64, ARM) to ensure that the application is compatible with all devices.

. NET native changed the way the packet was sent, which was the last major change to the workflow. A big feature of the. NET native is that the compiler can be placed in the cloud. When you compile an app package in Visual Studio, you create two packages, one is a. appxupload file, and the other is a "test". appx file for side loading: Appxupload contains the MSIL binaries and the. NET used by the app. Native tool chain version information (also recorded in the Appxmanifest.xml file). The compiled package is then placed in the store and then compiled by the same version of the. NET native Toolchain. Because the compiler is in the cloud, developers will be able to repeatedly modify program defects without having to recompile the application locally.

This change has brought two other changes to the developer workflow. The first is that developers cannot modify the fourth version number of an application package because the store needs to change the version number to mark every compilation behavior in the cloud. However, developers can also modify the other three version numbers, so there is no need to have too much doubt. The second is the need for developers to pay special attention to the packages uploaded to the store. The store replaces the developer for native compilation, so developers cannot upload native binaries generated by the local. NET native compiler. For this, Visual Studio helps developers choose the right file.

In summary, the most significant change that the. NET native brings is the following:

• Use release mode to periodically test developed applications
• Make sure that the Revision pack number is 0 (Visual Studio does not allow modifications and does not modify with a text editor)
• Upload only the. appxupload file that was generated when the package was created to the store. If you upload an. appx file for a universal Windows platform, the store will reject and error

other tips for using. NET native
If the developer suspects that the. NET native caused some errors, you can try the following workaround. Because release mode optimizes the code by default, it loses some of the generated files required in debug mode, so debugging in release mode may cause errors. Developers can create a new custom schema to use the. NET native toolchain without optimizing the code. More details can be seen here.

Avoiding. NET native-related errors from the start is undoubtedly a better choice. Microsoft.NET Native.analyzer If you encounter code that conflicts with. NET Native during development, a corresponding warning is given.

Thank Xuchuan for the review of this article.

To contribute to or participate in the content translation of the Infoq Chinese station, please email to [email protected]. You are also welcome to follow us through Sina Weibo (@InfoQ, @ Ding), (No.: Infoqchina), and to communicate with our editors and other readers (welcome to the InfoQ Reader Exchange Group).

"Qcon Shanghai 2015" experts gathered at home and abroad to understand the latest technology trends and best practices. Best-selling "illustration of the work of tomatoes" author Staffan N?teberg, Azul Systems co-founder and CTO, famous JVM expert Gil Tene, Uber chief system architect, distributed systems expert Matt Ranney and Twitter Heron Core Developer Fu Maosung with you qcon Shanghai! Learn more.

. NET Native: compiling. NET applications into native apps