Unni RavindranathanPrincipal PM Manager@unnir

Deep dive into XAML and .NET Universal Windows app development

2-790

ASSUMPTION: Knowledge of Windows and/or Windows Phone 8.1 XAML .NET development

OBJECTIVE: Understand key .NET development differences between Windows 8.1 and Universal Windows 10 app development

.NET Native

Next Generation Compiler in the Cloud for Store Apps

Provides converged developer experience for .NET across devices

Uses lean runtime and VC++ optimizer for fast code execution and reduced memory usage

Answer: Mobile app requirements

• Faster app startup times• No JIT would also imply less CPU cycles, hence longer battery life• Up to 60% savings on cold startup• Up to 40% savings on warm startup

• Smaller memory footprint• Whole program optimization removes unused types/functions• Up to 30% savings for apps

Why .NET Native?

Answer: Adaptive apps

• Writing code against APIs that don’t exist on a device becomes common

• JIT will cause the code above to crash on most Windows 10 devices

Why .NET Native?

Answer: Faster cadence

Why .NET Native?

• Coupling between Windows and .NET historically

• Ship .NET updates and tooling improvement faster

• Updates should not break developers• NET Native statically links (most) framework libraries with the app• Apps adopt library innovations on their cadence• Developers can be confident that Windows Update won’t break their app

• .NET Native was already being used by some Windows 8.1 apps as a pilot!

Did you know?

All Universal Windows 10 .NET apps delivered to consumer devices will be compiled with .NET Native

Developer workflow

Create a C#/VB Universal Windows Project

Develop and Debug

Debug x86|x64|ARM

Create package for store submission

Test Scenarios

Release x86|x64|ARM

Store compiles AppX w/ .NET Native Toolchain

Consumer Devices install .NET Native enabled AppX packages

Anatomy of a Universal Windows app projectDemo

Developer workflow

Create a C#/VB Universal Windows Project

Build & Run

Debug x86|x64|ARM

Created package for Store submission

Test Scenarios

Release x86|x64|ARM

Store compiles AppX w/ .NET Native Toolchain

Consumer Devices install .NET Native enabled AppX packages

Uses AppLocal CoreCLR runtime WinMetadata\Windows.winmd for avoiding JIT failures.NET references are copied local to the package

Uses .NET Native toolchainUpload Release .appxupload files to the Store Side-load Release AppX packagesPackage revision is reserved for store-side compilation

• Deployment targets• x86 for local machine, Simulator and Emulator scenarios• ARM for phone devices

• Library authors can still ship binaries as AnyCPU

Looking for feedback here!

But I love my AnyCPU…

• Debug• AppX packages defaulted to MSIL• No .appxupload files created

• Release• AppX packages defaulted to .NET Native• Used for enterprise/side-loading scenarios

• Packages in .appxupload are MSIL• Store will reject .NET Native package submissions

Default Packaging options at VS 2015 RTM

Default policy is conservative for apps

Used to declare what Metadata and Types to keep• Flexible to allow assembly, namespace or type-level

specifications• Developers can change policy to decrease app footprint

Control library authors• Use rd.xml as an embedded resource to specify

types/properties that are used via Reflection

Runtime Directives (rd.xml)

Runtime DirectivesDemo

• Develop your application using Debug

• Periodically test your application using Release• Issues specific to .NET Native can be better diagnosed with .NET Native

enabled in Debug builds

• Submitting AppX to store• Common scenario is AppXUpload• Create custom Release build packages with

<EnableDotNetNative>False</EanableDotNetNative>

.NET Native best practices

• Developer experience improvements around build throughput and incremental build

• Introduction of a shared framework package that reduces per-app size-on-disk

.NET Native running backlog

• Maintain forks of your sources

• .NET Native compilation happens in the cloud

• Symbols available on the Developer portal

Post mortem debugging

• Edit-n-Continue• IntelliTrace• Just my Code• Obfuscation

VS .NET Native unsupported experiences

• Universal Windows 10 apps will have the same base surface area as Windows 8.1• And yes, that means WCF works on Phone

• Future libraries will be delivered out-of-band via NuGet• First examples in default project templates:

System.Numerics.Vector.dll, etc.

.NET Framework evolution

• Portable Class Libraries• PCLs that target .NETCore 4.5.1 should work as-is

• Native references• Windows or Windows Phone 8.1 component• Reference the Visual Studio 2013 CRT packaged as Universal Windows

App package

• Universal Windows App competent• Reference the Visual Studio 2015 CRT package

• Your app can use both sets of references!

Consuming libraries in your .NET app

• Report any issues to dotnetnative@microsoft.comunnir@microsoft.com

• Runtime Directives specification, how .NET Native works

Resources

Related sessions

Session Code

Title Speaker

2-614 A Lap Around .NET 2015 Jay Schmelzer

2-697 New XAML Tools in Visual Studio 2015 Unni Ravindranathan

2-650 Developing Universal Windows app in Visual Studio 2015

Navit Saxena

2-639 What’s new in XAML for Universal Windows apps Joe Stegman

3-733 API Contracts Brent Rector

Questions?

Unni Ravindranathanunnir@microsoft.com @unnir

© 2015 Microsoft Corporation. All rights reserved.