Windows 10: .NET Native – What is for Universal Windows Platform (UWP) developers

Brink · Aug 19, 2015

What is .NET Native?

.NET Native is a precompilation technology for building Universal Windows apps in Visual Studio 2015. The .NET Native toolchain will compile your managed IL binaries into native binaries. Every managed (C# or VB) Universal Windows app will utilize this new technology. The applications are automatically compiled to native code before they reach consumer devices. If you’d like to dive deeper in how it works, I highly recommend reading more on it at MSDN.

How does .NET Native impact me and my app?

Your mileage likely will vary, but for most cases your app will start up faster, perform better, and consume fewer system resources.

Up to 60% performance improvement on cold startup times

Up to 40% performance improvement on warm startup times

Less memory consumption of your app when compiled natively

No dependencies on the desktop .NET Runtime installed on the system

Since your app is compiled natively, you get the performance benefits associated with native code (think C++ performance)

You can still take advantage of the industry-leading C# or VB programming languages, and the tools associated with them

You can continue to use the comprehensive and consistent programming model available with .NET– with extensive APIs to write business logic, built-in memory management, and exception handling.

You get the best of both worlds, managed development experience with C++ performance. How cool is that?

Debug versus Release compile configuration differences

.NET Native compilation is a complex process, and that makes it a little slower when compared to classic .NET compilation. The benefits mentioned above come at a cost of compilation time. You could choose to compile natively every time you want to run your app, but you’d be spending more time waiting for the build to finish. The Visual Studio tooling is designed to address this and create the smoothest possible developer experience.

When you build and run in “Debug” configuration, you are running IL code against the CoreCLR packaged within your application. The .NET system assemblies are packaged alongside your application code, and your application takes a dependency on the Microsoft.NET.CoreRuntime (CoreCLR) package.

This means you get the best development experience possible – fast compilation and deployment, rich debugging and diagnostics, and all of the other tools you are accustomed to with .NET development.

When you switch to “Release” mode, by default your app utilizes the .NET Native toolchain. Since the package is compiled to native binaries, the package does not need to contain the .NET framework libraries. In addition, the package is dependent on the latest installed .NET Native runtime as opposed to the CoreCLR package. The .NET Native runtime on the device will always be compatible with your application package.

Local native compilation via the “Release” configuration will enable testing your application in an environment that is similar to what your customers will experience. It is important to test this on a regular basis as you proceed with development.

A good rule of thumb is to test your app this way periodically throughout development to make sure you identify and correct any issues that may come from the .NET Native compiler. There should be no issues in the majority of cases; however, there are still a few things that don’t play so nicely with .NET Native. Four+ dimensional arrays are one such example. Ultimately, your customers will be getting the .NET Native compiled version of your application, so it is always a good idea to test that version throughout development and before shipping.

In addition to making sure you test with .NET Native compilation, you may also notice that the AnyCPU build configuration has disappeared. With .NET Native brought into the mix, AnyCPU is no longer a valid build configuration because native compilation is architecture dependent. An additional consequence of this is that when you package your application, you should select all three architecture configurations (x86, x64 and ARM) to make sure your application is applicable to as many devices as possible. This is the Universal Windows Platform after all. By default, Visual Studio will guide you to this as shown in the diagram below.

Figure 1 – All three architectures are selected by default

With that said, you can still build AnyCPU libraries and DLLs to be referenced in your UWP app. These components will be compiled to architecture specific binaries based on the configuration of the project (.appx) consuming it.

The last substantial change to your workflow as a result of .NET Native is how you create a store acceptable package. One great feature of .NET Native is that the compiler is capable of being hosted in the cloud. When you build your Store package in Visual Studio, two packages are created – one .appxupload and one “test” .appx for sideloading. The .appxupload contains the MSIL binaries as well as an explicit reference to the version of the .NET Native toolchain your app consumes (referenced in the AppxManifest.xml). This package then goes to the Store and is compiled using the exact same version of the .NET Native toolchain. Since the compiler is cloud hosted, it can be iterated to fix bugs without you having to recompile your app locally.

Figure 2 – The .appxupload goes to the store; the Test folder contains the sideloading appx package

This has two consequential changes to the developer workflow. The first is that you as a developer no longer have access to the revision number of your application package (the fourth one). The Store reserves this number as a way to iterate on the app package if for any reason the package is recompiled in the cloud. Don’t worry though, you still have control of the other three numbers.

The second is that you have to be careful about which package you upload to the Store. Since the Store does the native compilation for you, you cannot upload the native binaries generated by the local .NET Native compiler. The Visual Studio workflow will guide you through this process so you select the right package.

Figure 3 – Select “Yes” to upload to the Store

When you use the app packaging wizard to create your packages, you should make sure to select “Yes” when Visual Studio prompts you to create a package to upload to the Store. I also recommend selecting “Always” for the “Generate app bundle” option as this will ultimately result in a single .appxupload file that will be ready for upload. For full guidance on creating a Store package, you can take a look at Packaging Universal Windows apps for Windows 10.

To summarize, the main changes to your workflow as a result of .NET Native are:

Test your application using the “Release” configuration regularly

Make sure to leave your revision package number as “0” – Visual Studio won’t let you change this, but make sure you don’t change it in a text editor

Only upload the .appxupload generated on package creation to the Store – if you upload the UWP .appx, the store will reject it with errors

Some other tips for utilizing .NET Native

If you find any issues that you suspect are caused by .NET Native, there is a technique you can use to help debug the issue. Release configurations by default optimize the code which loses some artifacts used for debugging. As a result, trying to debug a Release configuration can result in some issues. What you can do instead is to create a custom configuration and enable the .NET Native toolchain for that configuration. Make sure to not optimize code. More details about this can be found here.

Now that you know how to debug issues, wouldn’t it be better if you could avoid them from the get-go? The Microsoft.NETNative.Analyzer can be installed in your application via NuGet. From the Package Manager Console, you can install the package via the following command: “Install-Package Microsoft.NETNative.Analyzer”. At development time, this analyzer will give you warnings if your code is not compatible with the .NET Native compiler. There is a small section of the .NET surface that is not compatible, but for the majority of apps this will never be a problem.

If you are curious about the startup time improvements of your app from .NET Native, you can try measuring it for yourself.

Known issues and workarounds

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

When you run the WACK on a UWP app that did not go through this compilation process, you will get a not-so-trivial failure. It will look something like:

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 fix is to make sure you are creating your packages properly, and running WACK on the right one. If you follow these packaging guidelines, you should never encounter this issue.

.NET Native applications that use reflection may fail the Windows App Cert Kit (WACK) with a false reference to Windows.Networking.VpnTo fix this, in the rd.xml file in your solution explorer, add the following line and rebuild:

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

Closing thoughts

All Windows users will benefit from .NET Native. Managed apps in the Store will start and run faster. Developers will have the .NET development experience they are used to with Visual Studio, and customers get the performance boosts of native code. If you’d like to provide feedback, please reach out at UserVoice. If you have a bug to report, you can file it at Connect.
Click to expand...

Source: .NET Native – What it means for Universal Windows Platform (UWP) developers | Building Apps for Windows

:)

Ronnie Vernon · Aug 19, 2015

Windows 10:What are the diffrences and contrast between a Store App and a Desktop App?

I had been browsing this store apps and desktops apps,

What are the diff and contrast between a Store App and a Desktop App?,

How are they structured and work?,

What do they have common?
Click to expand...

Hi

Store Apps = Universal Windows Platform code.

Desktop Programs = Win32 and COM code.

This is a very, very, complex subject. Here are a few links to get you started understanding the difference.

The Microsoft developers are working on merging these 2 coding platforms.

Win32 and COM for Universal Windows Platform (UWP) apps (data)

Win32 and COM for Universal Windows Platform (UWP) apps (data) - Windows app development

Guide to Universal Windows Platform (UWP) apps:

What's a Universal Windows Platform (UWP) app? - UWP app developer

Bring your desktop app to the Universal Windows Platform - Links + Video:

Convert your desktop app to a UWP app and enhance it with features such as Live Tiles, notifications, Cortana, and more!

Desktop conversion for UWP apps - Windows app development

Windows 8* Store vs Desktop App Development:

Windows 8* Store vs Desktop App Development | Intel® Software

Regards

Roharashraj™ · Aug 19, 2015

Microsoft will be charging for Windows update!

Microsoft has introduce "Windows Universal App"

Microsoft introduce Windows 10 for the betterment of Developers & Consumers.

A Universal Windows Platform (UWP) app is a Windows experience that is built upon the Universal Windows Platform (UWP), which was first introduced in Windows 8 as the Windows Runtime. At the core of UWP apps is the idea that users want their
experiences to be mobile across ALL their devices, and they want to use whatever device is most convenient or productive for the task at hand.

Windows 10 makes it easier to develop apps for the UWP with just one API set, one app package, and one store to reach all Windows 10 devices – PC, tablet, phone, Xbox, HoloLens, Surface Hub and more. It’s easier to support a number of screen sizes, and also
a variety of interaction models, whether it be touch, mouse and keyboard, a game controller, or a pen.

The bottom line: You can spend your time working with familiar programming languages and APIs, all in single project, and have the very same code run on the huge range of Windows hardware that exists today.

You may read an entire article at Microsoft Developer Network,
Click Here

Windows 10: .NET Native – What is for Universal Windows Platform (UWP) developers

.NET Native – What is for Universal Windows Platform (UWP) developers

.NET Native – What is for Universal Windows Platform (UWP) developers

.NET Native – What is for Universal Windows Platform (UWP) developers - Similar Threads - NET Native –

latest win11 updated AMD Radeon™ Graphics product with a Universal Windows Platform UWP...

What is The Difference Between .Net Runtime & .Net Developer Pack?

AI Platform for Windows Developers

The path from a desktop app to a Universal Windows Platform (UWP) app

NET Framework - NET Core Preview Any developer, any app, any platform

Universal Windows Platform (UWP) docs are now on Docs.Microsoft.com

React Native on the Universal Windows Platform

A deeper dive into the Universal Windows Platform

Guide to Universal Windows Platform (UWP) apps