<<

.NET Core: from architecture to code

Raffaele Rialdi @raffaeler [email protected] http://iamraf.net Big, big thanks to the Sponsors!!! About myself ... ▪ I started working professionally with software in 1987 ▪ In 2003 I received my first MVP Award (I got my 14th few days ago!) ▪ In a couple of weeks I will attend the MVP Summit in Redmond ▪ I am a Senior Software Architect ▪ Working as both as consultant and driving a a software division in Vevy Europe ▪ I have a lot of fun with exciting projects: ▪ Financial, Racing, Manufacturing, ... ▪ I have been in Romania several times  ▪ «Visual Studio 2010 Launch» Keynote in Bucharest ▪ Regular speaker in ITCamp @ Cluj Napoca since 2012 Rationale for re-architecting the .NET Framework

▪ Rebuild the .NET platform to reach new goals ▪ Cross-platform: we live in an etherogeneous world ▪ Remove global dependencies: making xcopy work everywhere ▪ better versioning, side-by-side deployment ▪ Easier load balancing and designing scalable apps ▪ Getting better performance from modern hardware ▪ No compromises ▪ But looking for the lowest possible breaking changes .NET Framework (versions 1.0 to 4.62)

▪ 15 years, 1.8 billion installations VB ++ C# F# … ▪ Multiple codebase/flavors Common Language Specification .NET Framework ▪ Desktop, Silverlight Ado.net Asp.net Winform WPF ... ▪ - Windows Base Class Library (BCL) ▪ Compact Framework ▪ ARM – Windows CE (CLR) ▪ Micro Framework ▪ ARM Duplicated BCL Codebase .NET ▪ Non-Microsoft .NET ▪ Mono / & ▪ , iOS, MacOS, … Compact Silverlight Framework ... ▪ x86 and ARM Micro Framework

proportions do not reflect real API numbers What is Net Core The details and ▪ Technically a «fork» of the .NET Framework a lot of code ▪ New runtime (Common Language Runtime – CLR) in the next session ▪ New libraries (Base Class Library – BCL) (same room) ▪ Changes to make the Cross Platform story work

▪ Scenarios taking advantace from Net Core (currently) are: ▪ ASP.NET Core: new ASP.NET stack, re-written from scratch ▪ Universal Windows Platform: Windows Store Apps (cross-device) ▪ Containerized applications / docker - ready ▪ Cloud Applications: Applications and Microservices running on Azure ▪ Console Application: the best way to start testing Net Core Cross-Platform = No first-class

▪ Official daily compilations on GitHub include many OSes ▪ CentOS, Debian, FreeBSD, openSUSE, RedHat, Linux Mint, Ubuntu 14.04 to 16.10 ▪ OSX 10.11 ▪ Windows Occasionally this may happen :) The Big Picture

▪ Libraries using just CoreFX can be shared across all the Application Models ▪ Runtime Adaptation Layers are specific to a given Platform / CPU ▪ x86, x64, ARM, ... .NET Framework .NET CORE Xamarin / Mono (more CPUs are coming in town) "Classic"

Win WPF iOS Android Forms ASP.NET UWP CORE … ▪ Modular design for future extensions ASP.NET OS X

▪ New Application Models CoreFX ▪ New Operating Systems / Platforms .NET Standard Library Runtime Adaption Level Runtime Adaption Level … ▪ New CLR variants CoreCLR .NET Native … The unified Command Line called "dotnet"

The CLI (Command Line Interface) is back ▪ In the cross-platform world is the common denominator ▪ Nanoservers, IoT devices, etc. are controlled using the command line ▪ Deploy tasks can be automated ▪ Easy to install on a fresh machine ▪ Visual Studio will provide the UI for all the CLI commands ▪ Support "extensions" to add commands ▪ downloaded via dotnet restore http://dot.net/

Hands on the DotNet CLI https://github.com/dotnet/cli

1. Install the CLI C:\app1>dotnet --help .NET Command Line Tools http://dot.net/ Usage: dotnet [common-options] [command] [arguments]

Arguments: 2. Create an App [command] The command to execute mkdir myapp [arguments] Arguments to pass to the command cd myapp Common Options (passed before the command): dotnet new -v|--verbose Enable verbose output --version Display .NET CLI Version Number --info Display .NET CLI Info 3. Write some code ... Common Commands: new Initialize a .NET project restore Restore dependencies specified in the .NET project 4. Restore packages build Builds a .NET project dotnet restore publish Publishes a .NET project for deployment (including the runtime) run Compiles and immediately executes a .NET project 5. Run the app test Runs unit tests using the test runner specified in the project pack Creates a NuGet package dotnet run An example of the dotnet CLI extensibility The Secret Manager Tool

▪ Warning: This tool is not suitable for production (data is NOT encrypted) ▪ It is an extension to the dotnet CLI "tools": { ▪ reference in the project ".Extensions.SecretManager.Tools": { "version": "1.0.0-preview1-final", ▪ dotnet restore to download "imports": "portable-net45+win8+dnxcore50" }} ▪ Usage is very simple dotnet user-secrets -h dotnet user-secrets set key 1234 ▪ Secrets are stored in the user profile dotnet user-secrets list ▪ Windows: %APPDATA%\microsoft\UserSecrets\\secrets.json ▪ Linux: ~/.microsoft/usersecrets//secrets.json ▪ Mac: ~/.microsoft/usersecrets//secrets.json NetStandard https://github.com/dotnet/standard/ ▪ A library specification defining a set of with no implementation ▪ Think to netstandard as it was a huge interface ▪ NET Frameworks provide at least a concrete implementation of all those APIs ▪ NET Core / CoreFX provides one of these implementations ▪ CoreFX is an implementation (superset) of NetStandard ▪ https://github.com/dotnet/corefx ▪ How the review board defines the surface of netstandard ▪ No platform specific APIs ▪ Only APIs that makes sense should be everywhere ▪ Is not necessary to put in the standard things that are IL-only (like C#, VB and F#) NetStandard versions vs Platforms

more Frameworks more APIs

No breaking changes between 1.x and 2.0 as initially announced

Version # of APIs netstandard 1.6 13,501 netstandard 2.0 32,638

Unity will be there too (they are going to use the upcoming mono release) How much is different netstandard (and CoreFX) from the current BCL? ▪ AppDomain ▪ Back in nestandard2.0, not available in netstandard1.6 ▪ CreateDomain throws PlatformNotSupportedException on some platforms ▪ AssemblyLoadContext to dynamically load assemblies ▪ AppContext to access few global data (GetData, SetData, ...) ▪ Remoting not available anymore ▪ MarshalByRefObject exists for compatibility reasons ▪ System.Data (only the abstractions and DataSet) but no providers ▪ System.Reflection now lives in a separate ▪ To avoid a complex dependency graph, GetTypeInfo() extension method exists Project.json ▪ Warning: tooling and project structure is going to change in the final bits ▪ Expect an «automagical» migration from project.json back to csproj ▪ Project.json accomplish multiple tasks. The most important are: ▪ dependencies: replace packages.config nuget configuration file ▪ frameworks: specify the targets where the application or library may run on ▪ net core, .net framework "classic", uap, etc. ▪ runtimes: constrains the application / library to a specific runtime platform ▪ win, ubuntu.14.04-x64, etc. ▪ buildOptions: compilation and friends ▪ assembly-wide (name, author, description, etc.) Project.json frameworks and dependencies ▪ "frameworks" is the section where we declare what CLR we want to use ▪ "netcoreapp1.0" is the moniker for .NET Core ▪ "net461" is the moniker for .NET Framework 4.61 ▪ complete list at https://docs.nuget.org/ndocs/schema/target-frameworks ▪ "dependencies" is where we declare the list of the required bits ▪ Class Libraries / DLL depends at least from "NETStandard.Library" ▪ Version "1.6.0" is the latest, soon the 2.0 ▪ Application Models / Apps depends at least from "Microsoft.NETCore.App" ▪ Currently version "1.0.0" and "1.0.1" are available ▪ Important note: dependencies may be "global" or specific to a specified framework Tooling ▪ Tooling is still in preview and miss a lot of things ▪ On October 19 the team announced the tooling for Visual Studio “15” ▪ Ability for current Net Framework projects to directly reference NetCore libraries ▪ Ability for NetCore project to reference Net Framework compatible libraries ▪ Transparent migration from project.json+xproj to csproj (the new one) ▪ using both "command line" or VS "15" UI ▪ nuget ▪ is expected to provide a better story around deployment (local and remote) ▪ dotnet cli ▪ the communities expect it to be expanded to support more options Packaging with Nuget

▪ NetCore dependencies must always be identified ▪ A package manager is required to identify the unit of deployment ▪ Nuget is now a leading actor in the build process ▪ Restore the dependencies from the known repositories (local or remote) ▪ Create packages for the libraries ▪ Resolve the dependency trees and identifies the versioning conflicts ▪ Cross-runtime and cross-framework packages will be even more popular ▪ Demo! Codecamp Feedback

https://goo.gl/FK2LGL Room 1 Questions?

Thank you!