Being back home from this year’s //BUILD/ conference, it is time to catch up on some of the missed sessions (or even rewatch some of those attended). As I’m used to take notes for future reference, I might as well share them with you, trying to conserve some keystrokes.
Session url: http://channel9.msdn.com/Events/Build/2015/2-790
Objective: Understand key .NET development differences between Windows 8.1 and Universal Windows 10 app development
.NET Native
Next generation compiler that compiles to the actual bits (instead of MSIL) to answer to mobile app requirements:
- Faster app startup
- Smaller memory footprint
- Required for adaptive apps (write once, run everywhere) against API that doesn’t exist. With JIT this code would just crash with e.g. a TypeLoadException.
- Allows Microsoft to release APIs faster than their large update cycles as the compiler statically links the required runtime bits. So a Windows Update should not break your app.
Debug builds by default x86|x64|ARM (possible to change to .NET Native with checkbox).
Release builds by default on .NET Native, so test your app in release as well.
The Windows Store compiles AppX with .NET Native in the cloud, so it can recompile and publish to clients when needed if there’s an important update to the runtime (security, performance, architecture, …).
Project properties
To target a newer version of the SDK: download it and target that version in the project properties. Use the min version property to tell the mininum required SDK version. No need to say it’s best to take the widest possible range.
Debug package
- Default MSIL as before, no .appxupload file.
- Your app runs versus a ‘private’ version (AppLocal) of the CoreCLR runtime. The contract which version you use is placed in the AppManifest at compile time.
- The WinMetadata folder of your package contains a ‘union’ metadata file (Windows.winmd) with all possible API calls available at that time (across all platforms) for resolving the types to prevent JIT failure and use the API checks for debugging.
- All linked .NET framework assemblies (as they would be linked by .NET Native toolchain).
Release package
Using the .NET Native toolchain takes some time (range of 25-50s is called), which has a negative impact on productivity. That’s why .NET Native is off in debug by default.
- No changes to the AppManifest referencing the CoreCLR, but metadata that tracks the used toolchain version.
- Quite ’large’ statically linked dll (Microsoft is working on a shared framework package to reduce the per-app size).
- AppX package in .NET Native for sideloading and .appxupload for the store in MSIL (which is compiled to .NET Native in the cloud)
AnyCPU
It’s gone!
- Test your app against the device in the real deployment target x86 <> ARM (instead of relying on the magic behind AnyCPU).
- Library authors can still ship binaries as AnyCPU.
Runtime Directives (rd.xml)
- Used to declare what Metadata and Types to keep in your statically linked package, conservative by default but can be tweaked by developers to decrease app footprint.
- Use rd.xml as an embedded resource as library author so the developer knows what you need (in case he wants to trim).
Post mortem debugging
All the .NET Native talk is nice, but what about debugging an end-users crash:
- Maintain forks of your code
- Symbols are available on the developer portal after the cloud compilation.
Limitations of .NET Native
- Edit and continue
- IntelliTrace
- Just my Code debugging
- Obfuscation
Consuming libraries
- PCL for .NETCore 4.5.1 should work as-is. A Windows 10 profile is work in progress.
- Native references from WinRT code (Windows/Windows Phone 8.1), but also add VS 2013 CRT.