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
[Link] 5
.NET Core
.NET
Innovation
Open Source
CrossPlatform
.NET 2015
WPF
Windows
Forms
[Link]
(4 & 5)
[Link] 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
[Link] 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
[Link]
Roslyn is the basis for .NET
and Visual Studio vNext
Roslyn is OPEN SOURCE
[Link]
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
[Link]
[Link] 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
[Link] 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
[Link]
5
.NET Core 5
MSBuild
.NET Micro Framework
[Link] Web Pages
Openness
Community
Rapid
innovation
Kudu
Cecil
NuGet
Couchbase for .NET
[Link] [Link]
[Link] MVC
[Link] Web API Mimekit Mailkit [Link]
[Link] SignalR
Orchard CMS
Join the conversation
[Link]
@dotnetfdn
Orleans
Rx
(Reactive Extensions)
OWIN Authentication Middleware
Windows Azure .NET SDK
Salesforce Toolkits for .NET
Meet the people behind the .NET Foundation
[Link]
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 ([Link])
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
[Link]
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\[Link]
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 ([Link])
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 [Link] 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:
[Link], 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
[Link] 5
.NET Core
.NET
Innovation
Open Source
CrossPlatform