ADC 2020: Von .NET Standard zu .NET 5

Transcript

1. Von .NET Standard zu .NET 5 Immo Landwerth @terrajobst Program Manager .NET
2. For your benefit, the slides are in English Oder wer kann das hier übersetzen? ☺ Paket zur Festlung von Zielversionen für die portiebare .NET-Bibliothek Targeting Pack for portable class libraries Produktrückstandselement Backlog item
4. “But .NET Core isn’t mature yet.” …or is it?
5. .NET adoption Visual Studio +1 million new monthly active .NET developers in last year .NET on Linux >1 million publishes from Visual Studio to Linux .NET Core +600K new monthly active developers in last year
6. .NET ecosystem momentum insights.stackoverflow.com/survey/2019#most-loved-dreaded-and-wanted & insights.stackoverflow.com/survey/2020#most-loved-dreaded-and-wanted github.com/cncf/velocity/ octoverse.github.com/ www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext
7. .NET Core 3 Fastest adopted version of .NET, ever.
8. Adoption of .NET Standard
9. .NET without .NET Standard
10. .NET with .NET Standard .NET Standard
13. “But .NET Framework is this the most powerful .NET platform.” …or is it?
14. 0K 50K 100K 150K 200K 250K .NET Core 1.0 .NET Core 2.0 .NET Core 2.0 + Compat Pack .NET Core 3.0 + Compat Pack #.NET Framework APIs in .NET Core
15. 0K 50K 100K 150K 200K 250K .NET Core 1.0 .NET Core 2.0 .NET Core 2.0 + Compat Pack .NET Core 3.0 + Compat Pack Everything in .NET FX 4.8 #.NET Framework APIs in .NET Core
16. 0K 50K 100K 150K 200K 250K .NET Core 1.0 .NET Core 2.0 .NET Core 2.0 + Compat Pack .NET Core 3.0 + Compat Pack Everything in .NET Core 3.0 Everything in .NET FX 4.8 #.NET Framework APIs in .NET Core
17. Journey to .NET 5
18. – .NET 5 to 6 "wave" .NET Framework Mono / Xamarin .NET Core .NET Single SDK, one BCL, unified toolchain Cross-platform native UI Cross-platform web UI Cloud native investments Continue improvements in speed, size, diagnostics, Azure services .NET has the best of breed solutions for all modern workloads One .NET vision
19. What does this actually mean? .NET Framework 4.8 Mono / Xamarin .NET Core 3.1 .NET Core 4.0 .NET 5.0 No more features, only fixes .NET 6
20. How do you target .NET? By using a TFM.  Target Framework Moniker  An identifier with a version that represents an API set  Have a long form (“.NETFramework, Version=4.5”) and a short form (“net45”)  Burnt into the assembly via the TargetFrameworkAttribute  Used for quirking  Used in NuGet packages as folders to house different implementations for different frameworks  Part of the .NET Standard support matrix  Very visible part of the .NET developer experience
21. Examples of NuGet packages and TFMs Newtonsoft.Json • net20 • net35 • net40 • net45 • netstandard1.0 • netstandard1.3 • netstandard2.0 • portable-net40+sl5+win8+wp8+wpa81 • portable-net45+win8+wp8+wpa81 SkiaSharp • monoandroid • netstandard1.3 • tizen40 • uap10.0 • Xamarin.iOS • Xamarin.Mac20 • Xamarin.TVOS • Xamarin.WatchOS System.Text.Json • net461 • netcoreapp3.0 • netstandard2.0 Xamarin.Essentials • monoandroid60 • monoandroid70 • monoandroid71 • monoandroid80 • monoandroid81 • monoandroid90 • net45 • netstandard1.0 • netstandard2.0 • tizen40 • uap10.0.16299 • xamarinios10 • xamarintvos10 • xamarinwatchos10
22. Why can’t we just have a single TFM?  Moving forward, we can assume the .NET platform APIs to be the same across all environments .NET <version> runs on  But this doesn’t include .NET bindings for OS APIs, such as:  WinRT  iOS bindings  Android bindings  Web assembly host APIs  We could make all APIs available everywhere by throwing  But would cause significant bloat for any library that bridges OS differences  So we need multi-targeting, meaning compiling for multiple frameworks
23. We want to support multi-targeting (1)  .NET has always been about letting developers leverage underlying OS functionality with ease (compare P/Invoke with JNI, for example)  Developers should be able to write code like this public static class GpsLocation { public static (double Latitude, double Longitude) GetCoordinates() { #if IOS return AppleAPI(); #elif Android return AndroidAPI(); #elif WINDOWS_UWP return UwpAPI(); #else throw new PlatformNotSupportedException(); #endif } }
24. We want to support multi-targeting (2)  For the best developer experience, library authors also want to provide different API surfaces for different platforms: public class SkiaSharpImage { #if IOS public SkiaSharpImage(NSImage nativeImage) { … } #endif #if Android public SkiaSharpImage(Android.Media.Image nativeImage) { … } #endif #if UWP public SkiaSharpImage(Windows.Media.BitmapImage nativeImage) { … } #endif }
25. Two Options: 1. Use current TFMs 2. Improve TFMs
26. Option 1 or “the road not taken”  netcoreapp5.0 .NET 5 for Windows desktop apps and cross- platform cloud services & CLI tools  xamarin.<OS><version> .NET for <OS> <version> development.  netstandard5.0 .NET that can be shared across all application models.  <tizen, unity>… ❌ Naming doesn’t reflect how we position the product ❌ Still need to explain .NET Standard and .NET Core ❌ net5.0 doesn’t mean what people think it means ✔ Works with tooling as-is
27. Option 2 or “the road we actually took”  Let’s align the names by putting net5.0 in front of the TFMs:  net5.0  net5.0-windows, net5.0-ios, net5.0-android…  NuGet could use this prefix notation to automatically understand that net5.0 can be consumed from net6.0-windows, but not the other way around  In this notation, developers can intuitively understand compatibility relationships because they are expressed syntactically ✔ Naming reflects how we position the product ✔ No need to explain .NET Standard and .NET Core any more ✔ net5.0 means what people think it means ❌ Mostly works with tooling, but needs NuGet changes
28. The layers now make sense: netX.Y
29. “But cross-platform development is tedious and error prone.” …or is it?
30. Demo: X-platform development with .NET 5
31. What will Microsoft libraries target? • ASP.NET Core, EF, virtually all System.* packages, most libraries • netX.Y • WinForms-, WPF-, and (managed) UWP controls • netX.Y-windows • Xamarin Essentials, Xamarin Forms, MAUI • netX.Y • Plus each OS TFM that it provides additional APIs/implementations for • Azure SDK, Microsoft.Data.SqlClient and other packages that need to support .NET Framework • netstandard2.0
32. What should you target?  Continue to use netstandard2.0 to share code between .NET Framework and all other platforms.  Consider using netstandard2.1 to share code between Mono, Xamarin, and .NET Core 3.x (less relevant with .NET 6).  Use net5.0 for code sharing moving forward.
33.  .NET 5.0 release in November 2020  Major releases every year  LTS for even numbered releases  Predictable schedule, minor releases as needed .NET Schedule Dec 2019 .NET Core 3.1 LTS Nov 2020 .NET 5.0 Nov 2021 .NET 6.0 LTS Nov 2022 .NET 7.0 Nov 2023 .NET 8.0 LTS
34. OS Targeting
35. OS Versioning  We don’t control OS release (e.g. iOS, Android)  The OS portion is versioned:  net5.0-ios13.0  net5.0-android11.0  When we increase the set of OS bindings, you need to update the version number in the project file  The version number doesn’t represent the OS, it represents the version of the .NET OS bindings  but for simplicity we’ll align that version with the OS version
36. OS Targeting  Developers are generally expected to compile against the latest version of the OS SDK/.NET bindings  To run on earlier versions, you need to opt-in & guard public void OnClick(object sender, EventArgs e) { if (OperatingSystem.IsIOSVersionAtLeast(14)) NSFizBuzz(); } <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net5.0-ios14.0</TargetFramework> <SupportedOSPlatformVersion>13.0</SupportedOSPlatformVersion> </PropertyGroup> </Project>
37. www.dotnetconf.net
38. dot.net/get-dotnet5 dot.net/get-core3 Use it today! Try it and give feedback
39. Thank you! Immo Landwerth @terrajobst Program Manager .NET https://devblogs.microsoft.com/dotnet/the-future-of-net-standard
41. Option 2 or “what we actually did” TFM Compatible With Comments net5.0 net1..4 (with warning) netcoreapp1..3.1 (warning when WinForms/WPF is referenced) netstandard1..2.1 No WinForms or WPF net5.0-win netcoreapp1..3.1 (+everything else inherited from net5.0) WinForms + WPF and probably UWP net5.0-ios xamarin.ios (+everything else inherited from net5.0) net5.0-android xamarin.android (+everything else inherited from net5.0) Tizen, Unity… Will follow the Xamarin model
42. What about WASM?  We originally considered adding a TFM for WebAssembly, such as net5.0-wasm  It’s more like an instruction set (such as x86 or x64) than like an operating system  Execution model in the browser sandbox is a key differentiator  Modelled as a runtime check via OperatingSystem.IsBrowser()  You’ll get warnings when you use unsupported APIs in Blazor without checking.  There are runtime identifiers (RID) for WebAssembly  browser and browser-wasm.  Allows package authors to deploy different binaries for browser scenarios  Especially useful for native code which needs to be compiled to WebAssembly
43. Why not one TFM per app-model?  Why do neither ASP.NET, nor WinForms, WPF, or UWP get their own TFM?  We need to build apps that combine app models, such as a WPF app that hosts a UWP browser control as well as ASP.NET Core web API  We don’t want the complexity of having to define compatibility rules between net5.0-xxx and net5.0-yyyy  We tried this with Portable Class Libraries (PCLs) and it doesn’t work  Rather, sharing across is only possible via the net5.0 base TFM  We’ll have one TFM per OS