Dec 19, 2015
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
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
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)
• 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
• 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 [email protected]@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