C# produktivnost + C++

performanse = .NET Native

Agenda
What new in .NET 4.6 and VS 2015
Compiling .NET applications
RyuJIT next generation of JIT Compiler
.NET Native new way of compilation
.NET Native Demo
Runtime directive in .NET Native
Migration to .NET Native
Summary

The road ahead for .NET

ASP.NET 5

.NET Core

.NET
Innovation

Open Source

CrossPlatform

.NET 2015
WPF

Windows
Forms

ASP.NET
(4 & 5)

ASP.NET 5

Universal
Windows Apps

.NET Core 5

.NET Framework 4.6

.NET Native

CoreCLR

Modular and optimized

.NET libraries and runtimes

Fully-featured and integrated

.NET libraries and runtime for Windows

Shared
Runtime
components
RyuJIT + SIMD
Garbage
Collector

Libraries
Base class
libraries
NuGet
packages

Compilers
.NET Compiler Platform
(Roslyn)
Languages innovation

.NET Framework 4.6

.NET Framework
4.6

e
m
i
t
n in
o
i
t
u
l
Evo

.NET
Framework
4

.NET
Framework
4.5

.NET
Framework
4.5.1

.NET
Framework
4.5.2

Highly compatible, in-place

replacement for .NET 4, 4.5,
4.5.1, and 4.5.2
Full support of any .NET API
and Libraries in the market
WPF is the platform of choice
for desktop application
development
ASP.NET 5 is also supported
running on top of .NET 4.6
.NET 4.6 also gets the
investment on new compilers,
new Jit, and languages
innovation

WPF Improvements in .NET 4.6

Performance and reliability improvement on touch
stack

Touch events in multi-touch are reported more reliably

Better performance of touch when UI thread is busy

Scrolling and virtualization improvements

Reliable traversal in a list

Preventing layout cycles during virtualization

HDPI Improvements

Multi-dpi cursor and monitor support

Smarter rounding of framework elements

Connect bugs >10 votes reactivated for

WPF Tooling in VS 2015

The new Blend for Visual Studio 2015
Integrated with VS technologies like Solution Explorer, Team Explorer,
Editor

New Language Service based on Roslyn

Faster and more reliable
Code centric workspace in VS, In-place editing support for WPF

Debugging
UI Debugging Tools for Xaml, Debugger-Integrated Diagnostic Tools

Diagnostics

.NET Compiler
Platform (Roslyn)
FROM

C#, VB
Source code

.exe/.dil
IL assemblies

Isolated/closed compilers
Hard to extend dev experience

Established .NET compilers

Open platform
for developers

TO
API: open platform
Rich IDE experiences/refactoring
Code analysis
Custom diagnostics
Open Source compilers

C#, VB
Source code

.exe/.dil
IL assemblies

.NET Compilers Platform

(a.k.a. ROSLYN)

.NET Compiler
Platform
(Roslyn)
New public preview today! (April
2014)

Scenarios/usage
cases
C#
VB

Language and IDE

API

VS dev experience
extensibility

OS
S

Open Source

http://aka.ms/NETCompilerPlatform

Roslyn is the basis for .NET

and Visual Studio vNext
Roslyn is OPEN SOURCE
http://aka.ms/RoslynOSS

Universal Windows
Platform

Universal Windows Platform

Universal Windows
Platform
Shared across Windows and
Windows Phone apps

.NET Native highlights

Next Generation Compiler in the Cloud
for Store Apps
.NET Native
Native code compilation

Uses lean runtime and VC++ optimizer

for fast code execution and reduced
memory usage
Preview available from Visual Studio
http://aka.ms/dotnetnative

ASP.NET 5.0
Cloud-ready
Leaner, faster, simpler
Designed from top to bottom to
be ready for the cloud and crossplatform deployments

Modular and open

More flexible with open source
and modular implementation

Improved tooling and

frameworks
Deliver value faster with
improved tooling and frameworks

.NET Cross-Platform
Mobile apps

Services and Web

applications

.NET
Xamarin
Unity

ASP.NET 5
.NET Core
Windows

Linux

.NET Core cross-platformMono

Mac OS X

Mobile Development
and .NET/Xamarin
partnership

 Available Now!

.NET Core
Preview

.NET Core 5 on Windows

.NET Core 5 on Linux

.NET Core 5 on MacOS

The .NET Foundation

MVVM Light Toolkit

.NET API for Hadoop WebClient

MEF (Managed Extensibility Framework)

.NET Compiler Platform ("Roslyn") Thinktecture IdentityManager

.NET Map Reduce API for Hadoop

WnsRecipe
ASP.NET
5
.NET Core 5
MSBuild

.NET Micro Framework

ASP.NET Web Pages

Openness
Community
Rapid
innovation

Kudu

Cecil

NuGet

Couchbase for .NET

Xamarin.Mobile System.Drawing
ASP.NET MVC
ASP.NET Web API Mimekit Mailkit Xamarin.Auth

ASP.NET SignalR
Orchard CMS

Join the conversation

http://www.dotnetfoundation.org
@dotnetfdn

Orleans

Rx

(Reactive Extensions)

OWIN Authentication Middleware

Windows Azure .NET SDK

Salesforce Toolkits for .NET

Meet the people behind the .NET Foundation

http://www.dotnetfoundation.org/team

Compilation of .NET applications

Two ways of compilation MSIL to native
code
1.
2.

.NET Framework just-in-time (JIT) compiler

.NET Framework Native Image Generator (Ngen.exe)

JIT Compiler

JIT converts MSIL to native code at Run-Time at the user machine.

Developers build MSIL assemblies
MSIL assemblies run on different machines/architecture
MSIL assemblies contains managed code
JIT compilation converts IL code in to native and stores in to
memory
When the operation is called for the first time JIT converts this part
of the code in to native.
Some of the code can never be used

NGen.exe
It performs the conversion from MSIL to
native code before rather than while running
the application
It compiles entire assembly at a time, rather
than a method at a time
It persist the generated code in the Native
Image Cache as file on the disk

RyuJIT new .NET JIT Compiler

64 bit JIT twice slower than

32JIT
RyuJIT the same code base
as 32JIT
RyuJIT for 64 bit architecture
RyuJIT app 30% faster than
32JIT

Install and setting RYUJIT

two ways to turn on RyuJIT.
set an environment variable: COMPLUS_AltJit=*
for entire machine, set the registry key
HKLM\SOFTWARE\Microsoft\.NETFramework\AltJit to the string
"*".
Both methods cause the 64-bit CLR to use RyuJIT instead of
JIT64.
And both are temporary settingsinstalling RyuJIT doesnt
make any permanent changes to your machine (aside from
installing the RyuJIT files in a directory)

How to DISABLE RYUJIT

three ways to turn off RyuJIT.

Add config section:

<runtime>

<useLegacyJit enabled="0" />

</runtime>
set an environment variable: COMPLUS_useLegacyJit=1
for entire machine, set the registry key
HKLM\SOFTWARE\Microsoft\.NETFramework\useLegacyJit to the string "*".

Both methods cause the 64-bit CLR

to use JIT64 instead of RyuJIT.

.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

Why .NET Native?

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 dont 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
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 wont break their app

Did you know?

.NET Native was already being used by

some Windows 8.1 apps as a pilot!

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

Test Scenarios

Debug x86|x64|ARM

Release x86|x64|ARM

Consumer Devices install

.NET Native enabled
AppX packages

Create package for

store submission

Store compiles AppX

w/ .NET Native
Toolchain

Anatomy of a Universal Windows app

project
Demo

Developer workflow
Create a C#/VB
Universal
Windows Project

Build & Run

Test Scenarios

Debug x86|x64|ARM

Release x86|x64|ARM

Created package for

Store submission

Upload
Release
.appxupload
filesstore-side
to the Store
Uses
Native
Uses .NET
AppLocal
CoreCLR
runtime
Package
revision
istoolchain
reserved
for
Side-load
Release AppX packages
compilation
WinMetadata\Windows.winmd
for avoiding JIT
failures
.NET references are copied local to the package
Consumer Devices install
.NET Native enabled
AppX packages

Store compiles AppX

w/ .NET Native
Toolchain

But I love my AnyCPU

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

Library authors can still ship binaries as

AnyCPU

Default Packaging options at VS 2015

RTM
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

Runtime Directives (rd.xml)

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
Demo

.NET Native best practices

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 running backlog

Developer experience improvements

around build throughput and incremental

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

Post mortem debugging

Maintain forks of your sources
.NET Native compilation happens in the

cloud

Symbols available on the Developer portal

VS .NET Native unsupported

experiences
Edit-n-Continue
IntelliTrace
Just my Code
Obfuscation

.NET Framework evolution

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.

Consuming libraries in your .NET app

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!

Summary

Precompilation technology
Superior performance like C++
Productivity Development like C#
Optimized app memory usage
Only Windows Store App for now.

The road ahead for .NET

ASP.NET 5

.NET Core

.NET
Innovation

Open Source

CrossPlatform