diff --git a/docs/core/whats-new/dotnet-core-3-0.md b/docs/core/whats-new/dotnet-core-3-0.md index 812c738c8cac8..218a79ac697de 100644 --- a/docs/core/whats-new/dotnet-core-3-0.md +++ b/docs/core/whats-new/dotnet-core-3-0.md @@ -6,252 +6,147 @@ dev_langs: - "vb" author: thraka ms.author: adegeo -ms.date: 12/31/2018 +ms.date: 04/19/2019 --- -# What's new in .NET Core 3.0 (Preview 2) +# What's new in .NET Core 3.0 (Preview 3) -This article describes what is new in .NET Core 3.0 (preview 2). One of the biggest enhancements is support for Windows desktop applications (Windows only). By utilizing a .NET Core 3.0 SDK component called Windows Desktop, you can port your Windows Forms and Windows Presentation Foundation (WPF) applications. To be clear, the Windows Desktop component is only supported and included on Windows. For more information, see the section [Windows desktop](#windows-desktop) below. +This article describes what is new in .NET Core 3.0 (preview 3). One of the biggest enhancements is support for Windows desktop applications (Windows only). By using the .NET Core 3.0 SDK component Windows Desktop, you can port your Windows Forms and Windows Presentation Foundation (WPF) applications. To be clear, the Windows Desktop component is only supported and included on Windows. For more information, see the [Windows desktop](#windows-desktop) section later in this article. .NET Core 3.0 adds support for C# 8.0. -[Download and get started with .NET Core 3.0 Preview 2](https://aka.ms/netcore3download) right now on Windows, Mac and Linux. You can see complete details of the release in the [.NET Core 3.0 Preview 2 release notes](https://aka.ms/netcore3releasenotes). +[Download and get started with .NET Core 3.0 Preview 3](https://aka.ms/netcore3download) right now on Windows, Mac, and Linux. You can see complete details of the release in the [.NET Core 3.0 Preview 3 release notes](https://aka.ms/netcore3releasenotes). For more information about what was released with each version, see the following announcements: -- [.NET Core 3.0 Preview 1 announcement](https://devblogs.microsoft.com/dotnet/announcing-net-core-3-preview-1-and-open-sourcing-windows-desktop-frameworks/) +- [.NET Core 3.0 Preview 3 announcement](https://devblogs.microsoft.com/dotnet/announcing-net-core-3-preview-3/) - [.NET Core 3.0 Preview 2 announcement](https://devblogs.microsoft.com/dotnet/announcing-net-core-3-preview-2/) +- [.NET Core 3.0 Preview 1 announcement](https://devblogs.microsoft.com/dotnet/announcing-net-core-3-preview-1-and-open-sourcing-windows-desktop-frameworks/) -## C# 8 - -.NET Core 3.0 supports C# 8, and as of .NET Core 3.0 Preview 2, supports these new features. For more information about C# 8.0 features, see the following blog posts: - -- [Do more with patterns in C# 8.0](https://devblogs.microsoft.com/dotnet/do-more-with-patterns-in-c-8-0/) -- [Take C# 8.0 for a spin](https://devblogs.microsoft.com/dotnet/take-c-8-0-for-a-spin/) -- [Building C# 8.0](https://devblogs.microsoft.com/dotnet/building-c-8-0/) - -### Ranges and indices - -The new `Index` type can be used for indexing. You can create one from an `int` that counts from the beginning, or with a prefix `^` operator (C#) that counts from the end: - -```csharp -Index i1 = 3; // number 3 from beginning -Index i2 = ^4; // number 4 from end -int[] a = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; -Console.WriteLine($"{a[i1]}, {a[i2]}"); // "3, 6" -``` - -There is also a `Range` type, which consists of two `Index` values, one for the start and one for the end, and can be written with a `x..y` range expression (C#). You can then index with a `Range` in order to produce a slice: - -```csharp -var slice = a[i1..i2]; // { 3, 4, 5 } -``` -### Async streams -The `IAsyncEnumerable` type is a new asynchronous version of `IEnumerable`. The language lets you `await foreach` over `IAsyncEnumerable` to consume their elements, and use `yield return` to them to produce elements. +## .NET Core SDK Windows Installer -The following example demonstrates both production and consumption of async streams. The `foreach` statement is async and itself uses `yield return` to produce an async stream for callers. This pattern (using `yield return`) is the recommended model for producing async streams. +The MSI installer for Windows has changed starting with .NET Core 3.0. The SDK installers will now upgrade SDK feature-band releases in place. Feature bands are defined in the *hundreds* groups in the *patch* section of the version number. For example, **3.0.*101*** and **3.0.*201*** are versions in two different feature bands while **3.0.*101*** and **3.0.*199*** are in the same feature band. And, when .NET Core SDK **3.0.*101*** is installed, .NET Core SDK **3.0.*100*** will be removed from the machine if it exists. When .NET Core SDK **3.0.*200*** is installed on the same machine, .NET Core SDK **3.0.*101*** won't be removed. -```csharp -async IAsyncEnumerable GetBigResultsAsync() -{ - await foreach (var result in GetResultsAsync()) - { - if (result > 20) yield return result; - } -} -``` +For more information about versioning, see [Overview of how .NET Core is versioned](../versions/index.md). -In addition to being able to `await foreach`, you can also create async iterators, for example, an iterator that returns an `IAsyncEnumerable/IAsyncEnumerator` that you can both `await` and `yield` in. For objects that need to be disposed, you can use `IAsyncDisposable`, which various BCL types implement, such as `Stream` and `Timer`. -> [!NOTE] -> You need .NET Core 3.0 Preview 2 to use async streams if you want to develop with either Visual Studio 2019 or the latest preview of the [C# extension for Visual Studio Code](https://github.com/OmniSharp/omnisharp-vscode/releases/tag/v1.18.0-beta5). If you are using .NET Core 3.0 Preview 2 at the command line, then everything will work as expected. -### Using Declarations +## C# 8.0 preview -*Using declarations* are a new way to ensure your object is properly disposed. A *using declaration* keeps the object alive while it is still in scope. Once the object becomes out of scope, it is automatically disposed. This will reduce nested *using statements* and make your code cleaner. +.NET Core 3.0 supports C# 8 preview. For more information about C# 8.0 features, see [What's new in C# 8.0](../../csharp/whats-new/csharp-8.md). -```csharp -static void Main(string[] args) -{ - using var options = Parse(args); - if (options["verbose"]) { WriteLine("Logging..."); } +## .NET Standard 2.1 -} // options disposed here -``` +Even though .NET Core 3.0 supports **.NET Standard 2.1**, the default `dotnet new classlib` template generates a project that targets **.NET Standard 2.0**. To target **.NET Standard 2.1**, edit your project file and change the `TargetFramework` property to `netstandard2.1`: -### Switch Expressions - -*Switch expressions* are a cleaner way of doing a *switch statement* but, since it's an expression, returns a value. *Switch expressions* are also fully integrated with pattern matching, and use the discard pattern, `_`, to represent the `default` value. - -You can see the syntax for *switch expressions* in the following example: - -```csharp -static string Display(object o) => o switch -{ - Point { X: 0, Y: 0 } => "origin", - Point { X: var x, Y: var y } => $"({x}, {y})", - _ => "unknown" -}; +```xml + + + + netstandard2.1 + + + ``` -There are two patterns at play in this example. `o` first matches with the `Point` *type pattern* and then with the *property pattern* inside the *{curly braces}*. The `_` describes the `discard pattern`, which is the same as `default` for *switch statements*. - -Patterns enable you to write declarative code that captures your intent instead of procedural code that implements tests for it. The compiler becomes responsible for implementing that boring procedural code and is guaranteed to always do it correctly. +If you're using Visual Studio, you need Visual Studio 2019 as Visual Studio 2017 doesn't support **.NET Standard 2.1** or **.NET Core 3.0**. -There will still be cases where *switch statements* will be a better choice than *switch expressions* and patterns can be used with both syntax styles. -For more information, see [Do more with patterns in C# 8.0](https://devblogs.microsoft.com/dotnet/do-more-with-patterns-in-c-8-0/). ## IEEE Floating-point improvements -Floating point APIs are in the process of being updated to comply with [IEEE 754-2008 revision](https://en.wikipedia.org/wiki/IEEE_754-2008_revision). The goal of these changes is to expose all "required" operations and ensure that they are behaviorally compliant with the IEEE spec. +Floating point APIs are being updated to comply with [IEEE 754-2008 revision](https://en.wikipedia.org/wiki/IEEE_754-2008_revision). The goal of these changes is to expose all **required** operations and ensure that they're behaviorally compliant with the IEEE spec. For more information about floating-point improvements, see the [Floating-Point Parsing and Formatting improvements in .NET Core 3.0](https://devblogs.microsoft.com/dotnet/floating-point-parsing-and-formatting-improvements-in-net-core-3-0/) blog post. -Parsing and formatting fixes: +Parsing and formatting fixes include: * Correctly parse and round inputs of any length. * Correctly parse and format negative zero. -* Correctly parse Infinity and NaN by performing a case-insensitive check and allowing an optional preceding `+` where applicable. +* Correctly parse `Infinity` and `NaN` by doing a case-insensitive check and allowing an optional preceding `+` where applicable. -New Math APIs have: +New APIs include: -* `BitIncrement/BitDecrement`\ +* and \ Corresponds to the `nextUp` and `nextDown` IEEE operations. They return the smallest floating-point number that compares greater or lesser than the input (respectively). For example, `Math.BitIncrement(0.0)` would return `double.Epsilon`. -* `MaxMagnitude/MinMagnitude`\ +* and \ Corresponds to the `maxNumMag` and `minNumMag` IEEE operations, they return the value that is greater or lesser in magnitude of the two inputs (respectively). For example, `Math.MaxMagnitude(2.0, -3.0)` would return `-3.0`. -* `ILogB`\ -Corresponds to the `logB` IEEE operation which returns an integral value, it returns the integral base-2 log of the input parameter. This is effectively the same as `floor(log2(x))`, but done with minimal rounding error. +* \ +Corresponds to the `logB` IEEE operation that returns an integral value, it returns the integral base-2 log of the input parameter. This method is effectively the same as `floor(log2(x))`, but done with minimal rounding error. -* `ScaleB`\ -Corresponds to the `scaleB` IEEE operation which takes an integral value, it returns effectively `x * pow(2, n)`, but is done with minimal rounding error. +* \ +Corresponds to the `scaleB` IEEE operation that takes an integral value, it returns effectively `x * pow(2, n)`, but is done with minimal rounding error. -* `Log2`\ +* \ Corresponds to the `log2` IEEE operation, it returns the base-2 logarithm. It minimizes rounding error. -* `FusedMultiplyAdd`\ +* \ Corresponds to the `fma` IEEE operation, it performs a fused multiply add. That is, it does `(x * y) + z` as a single operation, there-by minimizing the rounding error. An example would be `FusedMultiplyAdd(1e308, 2.0, -1e308)` which returns `1e308`. The regular `(1e308 * 2.0) - 1e308` returns `double.PositiveInfinity`. -* `CopySign`\ +* \ Corresponds to the `copySign` IEEE operation, it returns the value of `x`, but with the sign of `y`. -## .NET Platform Dependent Intrinsics -APIs have been added that allow access to certain perf-oriented CPU instructions, such as the **SIMD** or **Bit Manipulation instruction** sets. These instructions can help achieve big performance improvements in certain scenarios, such as processing data efficiently in parallel. In addition to exposing the APIs for your programs to use, the .NET libraries have begun using these instructions to improve performance. -The following CoreCLR PRs demonstrate a few of the intrinsics, either via implementation or use: +## .NET Platform-Dependent Intrinsics -* [Implement simple SSE2 hardware intrinsics](https://github.com/dotnet/coreclr/pull/15585) -* [Implement the SSE hardware intrinsics](https://github.com/dotnet/coreclr/pull/15538) -* [Arm64 Base HW Intrinsics](https://github.com/dotnet/coreclr/pull/16822) -* [Use TZCNT and LZCNT for Locate{First|Last}Found{Byte|Char}](https://github.com/dotnet/coreclr/pull/21073) +APIs have been added that allow access to certain perf-oriented CPU instructions, such as the **SIMD** or **Bit Manipulation instruction** sets. These instructions can help achieve significant performance improvements in certain scenarios, such as processing data efficiently in parallel. -For more information, see [.NET Platform Dependent Intrinsics](https://github.com/dotnet/designs/blob/master/accepted/platform-intrinsics.md), which defines an approach for defining this hardware infrastructure, allowing Microsoft, chip vendors, or any other company or individual to define hardware/chip APIs that should be exposed to .NET code. - -## Default executables +Where appropriate, the .NET libraries have begun using these instructions to improve performance. -.NET Core will now build [framework-dependent executables](../deploying/index.md#framework-dependent-executables-fde) by default. This is new for applications that use a globally installed version of .NET Core. Until now, only [self-contained deployments](../deploying/index.md#self-contained-deployments-scd) would produce an executable. +For more information, see [.NET Platform Dependent Intrinsics](https://github.com/dotnet/designs/blob/master/accepted/platform-intrinsics.md). -During `dotnet build` or `dotnet publish`, an executable is created provided that matches the environment and platform of the SDK you are using. You can expect the same things with these executables as you would other native executables, such as: -* You can double-click on the executable. -* You can launch the application from a command prompt directly, such as `myapp.exe` on Windows, and `./myapp` on Linux and macOS. - -## Build copies dependencies -`dotnet build` now copies NuGet dependencies for your application from the NuGet cache to the build output folder. Previously, dependencies were only copied as part of `dotnet publish`. +## Default executables -There are some operations, like linking and razor page publishing that will still require publishing. +.NET Core now builds [framework-dependent executables](../deploying/index.md#framework-dependent-executables-fde) by default. This behavior is new for applications that use a globally installed version of .NET Core. Previously, only [self-contained deployments](../deploying/index.md#self-contained-deployments-scd) would produce an executable. -## Local dotnet tools +During `dotnet build` or `dotnet publish`, an executable is created that matches the environment and platform of the SDK you're using. You can expect the same things with these executables as you would other native executables, such as: -> [!WARNING] -> There was a change in .NET Core Local Tools between .NET Core 3.0 Preview 1 and .NET Core 3.0 Preview 2. If you tried out local tools in Preview 1 by running a command like `dotnet tool restore` or `dotnet tool install`, you need to delete your local tools cache folder before local tools will work correctly in Preview 2. This folder is located at: -> -> On mac, Linux: `rm -r $HOME/.dotnet/toolResolverCache` -> -> On Windows: `rmdir /s %USERPROFILE%\.dotnet\toolResolverCache` -> -> If you do not delete this folder, you will receive an error. +* You can double-click on the executable. +* You can launch the application from a command prompt directly, such as `myapp.exe` on Windows, and `./myapp` on Linux and macOS. -While .NET Core 2.1 supported global tools, .NET Core 3.0 now has local tools. Local tools are similar to global tools but are associated with a particular location on disk. This enables per-project and per-repository tooling. Any tool installed locally isn't available globally. Tools are distributed as NuGet packages. -Local tools rely on a manifest file name `dotnet-tools.json` in your current directory. This manifest file defines the tools to be available at that folder and below. By creating this manifest file at the root of your repository, you ensure anyone cloning your code can restore and use the tools that are needed to successfully work with your code. -To create a `dotnet-tools.json` manifest file, use: +## Tiered compilation -```console -dotnet new tool-manifest -``` +[Tiered compilation](https://devblogs.microsoft.com/dotnet/tiered-compilation-preview-in-net-core-2-1/) is on by default with .NET Core 3.0. This feature enables the runtime to more adaptively use the Just-In-Time (JIT) compiler to get better performance. -Add a new tool to the local manifest with: +This feature was added as an opt-in feature in [.NET Core 2.1](https://devblogs.microsoft.com/dotnet/announcing-net-core-2-1/) and then was enabled by default in [.NET Core 2.2 Preview 2](https://devblogs.microsoft.com/dotnet/announcing-net-core-2-2-preview-2/). Subsequently, it has been reverted back to opt in with the .NET Core 2.2 release. -```console -dotnet tool install -``` -You can also list the tools in the local manifest with: -```console -dotnet tool list -``` +## Build copies dependencies -To see what tools are installed globally, use: +The `dotnet build` command now copies NuGet dependencies for your application from the NuGet cache to the build output folder. Previously, dependencies were only copied as part of `dotnet publish`. -```console -dotnet tool list -g -``` +There are some operations, like linking and razor page publishing that will still require publishing. -When the local tools manifest file is available, but the tools defined in the manifest have not been installed, use the following command to automatically download and install those tools: -```console -dotnet tool restore -``` -Run a local tool with the following command: +## Local tools -```console -dotnet tool run -``` +.NET Core 3.0 introduces local tools. Local tools are similar to [global tools](../tools/global-tools.md) but are associated with a particular location on disk. Local tools aren't available globally and are distributed as NuGet packages. -When a local tool is run, dotnet searches for a manifest up the current directory structure. When a tool manifest file is found, it is searched for the requested tool. If the tool is found in the manifest, but not the cache, the user receives an error and needs to run `dotnet tool restore`. +> [!WARNING] +> If you tried local tools in .NET Core 3.0 Preview 1, such as running `dotnet tool restore` or `dotnet tool install`, delete the local tools cache folder. Otherwise, local tools won't work on any newer release. This folder is located at: +> +> On macOS, Linux: `rm -r $HOME/.dotnet/toolResolverCache` +> +> On Windows: `rmdir /s %USERPROFILE%\.dotnet\toolResolverCache` -To remove a tool from the local tool manifest file, run the following command: +Local tools rely on a manifest file name `dotnet-tools.json` in your current directory. This manifest file defines the tools to be available at that folder and below. You can distribute the manifest file with your code to ensure that anyone who works with your code can restore and use the same tools. -```console -dotnet tool uninstall -``` +For both global and local tools, a compatible version of the runtime is required. Many tools currently on NuGet.org target .NET Core Runtime 2.1. To install these tools globally or locally, you would still need to install the [NET Core 2.1 Runtime](https://dotnet.microsoft.com/download/dotnet-core/2.1). -The tool manifest file is designed to allow hand editing – which you might do to update the required version for working with the repository. Here is an example `dotnet-tools.json` file: - -```json -{ - "version": 1, - "isRoot": true, - "tools": { - "dotnetsay": { - "version": "2.1.4", - "commands": [ - "dotnetsay" - ] - }, - "t-rex": { - "version": "1.0.103", - "commands": [ - "t-rex" - ] - } - } -} -``` -For both global and local tools, a compatible version of the runtime is required. Many tools currently on NuGet.org target .NET Core Runtime 2.1. To install those globally or locally, you would still need to install the [NET Core 2.1 Runtime](https://dotnet.microsoft.com/download/dotnet-core/2.1). ## Windows desktop -Starting with .NET Core 3.0 Preview 1, you can build Windows desktop applications using WPF and Windows Forms. These frameworks also support using modern controls and Fluent styling from the Windows UI XAML Library (WinUI) via [XAML islands](/windows/uwp/xaml-platform/xaml-host-controls). +.NET Core 3.0 supports Windows desktop applications using Windows Presentation Foundation (WPF) and Windows Forms. These frameworks also support using modern controls and Fluent styling from the Windows UI XAML Library (WinUI) via [XAML islands](/windows/uwp/xaml-platform/xaml-host-controls). The Windows Desktop component is part of the Windows .NET Core 3.0 SDK. @@ -262,534 +157,182 @@ dotnet new wpf dotnet new winforms ``` -Visual Studio 2019 adds **New Project** templates for .NET Core 3.0 Windows Forms and WPF. Designers are still not yet supported. And you can open, launch, and debug these projects in Visual Studio 2019. - -Visual Studio 2017 15.9 adds the ability to [enable .NET Core previews](https://devblogs.microsoft.com/dotnet/net-core-tooling-update-for-visual-studio-2017-version-15-9/), but you need to turn that feature on, and it's not a supported scenario. - -The new projects are the same as existing .NET Core projects, with a couple additions. Here is the comparison of the basic .NET Core console project and a basic Windows Forms and WPF project. - -In a .NET Core console project, the project uses the `Microsoft.NET.Sdk` SDK and declares a dependency on .NET Core 3.0 via the `netcoreapp3.0` target framework. To create a Windows Desktop app, use the `Microsoft.NET.Sdk.WindowsDesktop` SDK and choose which UI framework to use: - -```diff -- -+ - - Exe - netcoreapp3.0 -+ true - - -``` - -To choose Windows Forms over WPF, set `UseWindowsForms` instead of `UseWPF`: +Visual Studio 2019 adds **New Project** templates for .NET Core 3.0 Windows Forms and WPF. -```diff - - - Exe - netcoreapp3.0 -- true -+ true - - -``` +For more information about how to port an existing .NET Framework application, see [Port WPF projects](../porting/winforms.md) and [Port Windows Forms projects](../porting/wpf.md). -Both `UseWPF` and `UseWindowsForms` can be set to `true` if the app uses both frameworks, for example when a Windows Forms dialog is hosting a WPF control. -Please share your feedback on the [dotnet/winforms](https://github.com/dotnet/winforms/issues), [dotnet/wpf](https://github.com/dotnet/wpf/issues) and [dotnet/core](https://github.com/dotnet/core/issues) repos. ## MSIX Deployment for Windows Desktop -[MSIX](https://docs.microsoft.com/windows/msix/) is a new Windows app package format. It can be used to deploy .NET Core 3.0 desktop applications to Windows 10. +[MSIX](https://docs.microsoft.com/windows/msix/) is a new Windows application package format. It can be used to deploy .NET Core 3.0 desktop applications to Windows 10. The [Windows Application Packaging Project](https://docs.microsoft.com/windows/uwp/porting/desktop-to-uwp-packaging-dot-net), available in Visual Studio 2019, allows you to create MSIX packages with [self-contained](../deploying/index.md#self-contained-deployments-scd) .NET Core applications. -> [!NOTE] -> The .NET Core project file must specify the supported runtimes in the `` property: -> -> ```xml -> win-x86;win-x64 -> ``` - -## Fast built-in JSON support - -The .NET ecosystem has relied on [**Json.NET**](https://www.newtonsoft.com/json) and other popular JSON libraries, which continue to be good choices. **Json.NET** uses .NET strings as its base datatype, which are UTF-16 under the hood. - -The new built-in JSON support is high-performance, low allocation, and based on `Span`. Three new main JSON-related types have been added to .NET Core 3.0 the `System.Text.Json` namespace. - -### Utf8JsonReader - -`System.Text.Json.Utf8JsonReader` is a high-performance, low allocation, forward-only reader for UTF-8 encoded JSON text, read from a `ReadOnlySpan`. The `Utf8JsonReader` is a foundational, low-level type, that can be leveraged to build custom parsers and deserializers. Reading through a JSON payload using the new `Utf8JsonReader` is 2x faster than using the reader from **Json.NET**. It does not allocate until you need to actualize JSON tokens as (UTF-16) strings. - -This new API will include the following components: - -* In Preview 1: JSON reader (sequential access) -* Coming next: JSON writer, DOM (random access), poco serializer, poco deserializer - -Here is the basic reader loop for the `Utf8JsonReader` that can be used as a starting point: - -```csharp -using System.Text.Json; - -public static void Utf8JsonReaderLoop(ReadOnlySpan dataUtf8) -{ - var json = new Utf8JsonReader(dataUtf8, isFinalBlock: true, state: default); - - while (json.Read()) - { - JsonTokenType tokenType = json.TokenType; - ReadOnlySpan valueSpan = json.ValueSpan; - switch (tokenType) - { - case JsonTokenType.StartObject: - case JsonTokenType.EndObject: - break; - case JsonTokenType.StartArray: - case JsonTokenType.EndArray: - break; - case JsonTokenType.PropertyName: - break; - case JsonTokenType.String: - string valueString = json.GetStringValue(); - break; - case JsonTokenType.Number: - if (!json.TryGetInt32Value(out int valueInteger)) - { - throw new FormatException(); - } - break; - case JsonTokenType.True: - case JsonTokenType.False: - bool valueBool = json.GetBooleanValue(); - break; - case JsonTokenType.Null: - break; - default: - throw new ArgumentException(); - } - } - - dataUtf8 = dataUtf8.Slice((int)json.BytesConsumed); - JsonReaderState state = json.CurrentState; -} -``` - -### Utf8JsonWriter - -`System.Text.Json.Utf8JsonWriter` provides a high-performance, non-cached, forward-only way to write UTF-8 encoded JSON text from common .NET types like `String`, `Int32`, and `DateTime`. Like the reader, the writer is a foundational, low-level type, that can be leveraged to build custom serializers. Writing a JSON payload using the new `Utf8JsonWriter` is 30-80% faster than using the writer from **Json.NET** and does not allocate. - -Here is a sample usage of the `Utf8JsonWriter` that can be used as a starting point: - -```csharp -static int WriteJson(IBufferWriter output, long[] extraData) -{ - var json = new Utf8JsonWriter(output, state: default); - - json.WriteStartObject(); - - json.WriteNumber("age", 15, escape: false); - json.WriteString("date", DateTime.Now); - json.WriteString("first", "John"); - json.WriteString("last", "Smith"); - - json.WriteStartArray("phoneNumbers", escape: false); - json.WriteStringValue("425-000-1212", escape: false); - json.WriteStringValue("425-000-1213"); - json.WriteEndArray(); +The .NET Core project file must specify the supported runtimes in the `` property: - json.WriteStartObject("address"); - json.WriteString("street", "1 Microsoft Way"); - json.WriteString("city", "Redmond"); - json.WriteNumber("zip", 98052); - json.WriteEndObject(); - - json.WriteStartArray("ExtraArray"); - for (var i = 0; i < extraData.Length; i++) - { - json.WriteNumberValue(extraData[i]); - } - json.WriteEndArray(); - - json.WriteEndObject(); - - json.Flush(isFinalBlock: true); - - return (int)json.BytesWritten; -} +```xml +win-x86;win-x64 ``` -The `Utf8JsonWriter` accepts `IBufferWriter` as the output location to synchronously write the json data into, and you as the caller need to provide a concrete implementation. The platform does not currently include an implementation of this interface. For an example of `IBufferWriter`, see . - -### JsonDocument - -`System.Text.Json.JsonDocument` is built on top of the `Utf8JsonReader`. The `JsonDocument` provides the ability to parse JSON data and build a read-only Document Object Model (DOM) that can be queried to support random access and enumeration. The JSON elements that compose the data can be accessed via the `JsonElement` type which is exposed by the `JsonDocument` as a property called `RootElement`. The `JsonElement` contains the JSON array and object enumerators along with APIs to convert JSON text to common .NET types. Parsing a typical JSON payload and accessing all its members using the `JsonDocument` is 2-3x faster than **Json.NET** with very little allocations for data that is reasonably sized (i.e. < 1 MB). - -Here is a sample usage of the `JsonDocument` and `JsonElement` that can be used as a starting point: -```csharp -static double ParseJson() -{ - const string json = " [ { \"name\": \"John\" }, [ \"425-000-1212\", 15 ], { \"grades\": [ 90, 80, 100, 75 ] } ]"; - double average = -1; +## WinForms HighDPI - using (JsonDocument doc = JsonDocument.Parse(json)) - { - JsonElement root = doc.RootElement; - JsonElement info = root[1]; +.NET Core Windows Forms applications can set High DPI mode with . The `SetHighDpiMode` method sets the corresponding High DPI mode unless the setting has been set by other means like `App.Manifest` or P/Invoke before `Application.Run`. - string phoneNumber = info[0].GetString(); - int age = info[1].GetInt32(); +The possible `highDpiMode` values, as expressed by the enum are: - JsonElement grades = root[2].GetProperty("grades"); +* `DpiUnaware` +* `SystemAware` +* `PerMonitor` +* `PerMonitorV2` +* `DpiUnawareGdiScaled` - double sum = 0; - foreach (JsonElement grade in grades.EnumerateArray()) - { - sum += grade.GetInt32(); - } +For more information about High DPI modes, see [High DPI Desktop Application Development on Windows](/windows/desktop/hidpi/high-dpi-desktop-application-development-on-windows). - int numberOfCourses = grades.GetArrayLength(); - average = sum / numberOfCourses; - } - return average; -} -``` -## Assembly Unloadability +## Fast built-in JSON support -Assembly unloadability is a new capability of `AssemblyLoadContext`. This new feature is largely transparent from an API perspective, exposed with just a few new APIs. It enables a loader context to be unloaded, releasing all memory for instantiated types, static fields and for the assembly itself. An application should be able to load and unload assemblies via this mechanism forever without experiencing a memory leak. +.NET users have largely relied on [**Json.NET**](https://www.newtonsoft.com/json) and other popular JSON libraries, which continue to be good choices. **Json.NET** uses .NET strings as its base datatype, which is UTF-16 under the hood. -This new capability can be used for scenarios similar to: +The new built-in JSON support is high-performance, low allocation, and based on `Span`. Three new main JSON-related types have been added to .NET Core 3.0 the namespace. These types don't *yet* support plain old CLR object (POCO) serialization and deserialization. -* Plugin scenarios where dynamic plugin loading and unloading is required. -* Dynamically compiling, running and then flushing code. Useful for web sites, scripting engines, etc. -* Loading assemblies for introspection (like ReflectionOnlyLoad), although [MetadataLoadContext](#type-metadataloadcontext) (released in Preview 1) will be a better choice in many cases. +### Utf8JsonReader -For more information, see the [Using Unloadability](https://github.com/dotnet/coreclr/pull/22221) document. + is a high-performance, low allocation, forward-only reader for UTF-8 encoded JSON text, read from a `ReadOnlySpan`. The `Utf8JsonReader` is a foundational, low-level type, that can be used to build custom parsers and deserializers. Reading through a JSON payload using the new `Utf8JsonReader` is 2x faster than using the reader from **Json.NET**. It doesn't allocate until you need to actualize JSON tokens as (UTF-16) strings. -Assembly unloading requires significant care to ensure that all references to managed objects from outside a loader context are understood and managed. When the loader context is requested to be unloaded, any outside references need to have been unreferenced so that the loader context is self-consistent only to itself. +Here is an example of reading through the [**launch.json**](https://github.com/dotnet/samples/blob/master/core/whats-new/whats-new-in-30/cs/launch.json) file created by Visual Studio Code: -Assembly unloadability was provided in the .NET Framework by Application Domains (AppDomains), which are not supported with .NET Core. AppDomains had both benefits and limitations compared to this new model. Consider this new loader model to be more flexible and higher performant when compared to AppDomains. +[!CODE-csharp[Utf8JsonReader](~/samples/core/whats-new/whats-new-in-30/cs/program.cs#PrintJson)] -## Windows Native Interop +[!CODE-csharp[Utf8JsonReader](~/samples/core/whats-new/whats-new-in-30/cs/program.cs#PrintJsonCall)] -Windows offers a rich native API, in the form of flat C APIs, COM, and WinRT. Since .NET Core 1.0, **P/Invoke** has been supported. Now with .NET Core 3.0, support for the ability to **CoCreate COM APIs** and **Activate WinRT APIs** has been added. +### Utf8JsonWriter -You can see an example of using COM with the [Excel Demo source code](https://github.com/dotnet/samples/tree/master/core/extensions/ExcelDemo). + provides a high-performance, non-cached, forward-only way to write UTF-8 encoded JSON text from common .NET types like `String`, `Int32`, and `DateTime`. Like the reader, the writer is a foundational, low-level type, that can be used to build custom serializers. Writing a JSON payload using the new `Utf8JsonWriter` is 30-80% faster than using the writer from **Json.NET** and doesn't allocate. -## Type: SequenceReader +### JsonDocument -In .NET Core 3.0, `System.Buffers.SequenceReader` has been added which can be used as a reader for `ReadOnlySequence`. This allows easy, high performance, low allocation parsing of `System.IO.Pipelines` data that can cross multiple backing buffers. + is built on top of the `Utf8JsonReader`. The `JsonDocument` provides the ability to parse JSON data and build a read-only Document Object Model (DOM) that can be queried to support random access and enumeration. The JSON elements that compose the data can be accessed via the type that is exposed by the `JsonDocument` as a property called `RootElement`. The `JsonElement` contains the JSON array and object enumerators along with APIs to convert JSON text to common .NET types. Parsing a typical JSON payload and accessing all its members using the `JsonDocument` is 2-3x faster than **Json.NET** with little allocations for data that is reasonably sized (that is, < 1 MB). -The following example breaks an input `Sequence` into valid `CR/LF` delimited lines: +Here is a sample usage of the `JsonDocument` and `JsonElement` that can be used as a starting point: -```csharp -private static ReadOnlySpan CRLF => new byte[] { (byte)'\r', (byte)'\n' }; +Here is a C# 8.0 example of reading through the [**launch.json**](https://github.com/dotnet/samples/blob/master/core/whats-new/whats-new-in-30/cs/launch.json) file created by Visual Studio Code: -public static void ReadLines(ReadOnlySequence sequence) -{ - SequenceReader reader = new SequenceReader(sequence); +[!CODE-csharp[JsonDocument](~/samples/core/whats-new/whats-new-in-30/cs/program.cs#ReadJson)] - while (!reader.End) - { - if (!reader.TryReadToAny(out ReadOnlySpan line, CRLF, advancePastDelimiter:false)) - { - // Couldn't find another delimiter - // ... - } +[!CODE-csharp[JsonDocument](~/samples/core/whats-new/whats-new-in-30/cs/program.cs#ReadJsonCall)] - if (!reader.IsNext(CRLF, advancePast: true)) - { - // Not a good CR/LF pair - // ... - } - // line is valid, process - ProcessLine(line); - } -} -``` -## Type: MetadataLoadContext -The `MetadataLoadContext` type has been added that enables reading assembly metadata without affecting the caller’s application domain. Assemblies are read as data, including assemblies built for different architectures and platforms than the current runtime environment. `MetadataLoadContext` overlaps with the , which is only available in the .NET Framework. +## Interop improvements -`MetdataLoadContext` is available in the [System.Reflection.MetadataLoadContext package](https://www.nuget.org/packages/System.Reflection.MetadataLoadContext). It is a .NET Standard 2.0 package. +.NET Core 3.0 improves native API interop. -The `MetadataLoadContext` exposes APIs similar to the type, but is not based on that type. Much like , the `MetadataLoadContext` enables loading assemblies within an isolated assembly loading universe. `MetdataLoadContext` APIs return objects, enabling the use of familiar reflection APIs. Execution-oriented APIs, such as [MethodBase.Invoke](https://github.com/dotnet/corefx/blob/master/src/System.Reflection.MetadataLoadContext/src/System/Reflection/TypeLoading/Methods/RoMethod.cs#L127), are not allowed and will throw InvalidOperationException. +### Type: NativeLibrary -The following sample demonstrates how to find concrete types in an assembly that implements a given interface: + provides an encapsulation for loading a native library (using the same load logic as .NET Core P/Invoke) and providing the relevant helper functions such as `getSymbol`. For a code example, see the [DLLMap Demo](https://github.com/dotnet/samples/tree/master/core/extensions/AppWithPlugin). -```csharp -var paths = new string[] {@"C:\myapp\mscorlib.dll", @"C:\myapp\myapp.dll"}; -var resolver = new PathAssemblyResolver(paths); -using (var lc = new MetadataLoadContext(resolver)) -{ - Assembly a = lc.LoadFromAssemblyName("myapp"); - Type myInterface = a.GetType("MyApp.IPluginInterface"); - foreach (Type t in a.GetTypes()) - { - if (t.IsClass && myInterface.IsAssignableFrom(t)) - Console.WriteLine($"Class {t.FullName} implements IPluginInterface"); - } -} -``` +### Windows Native Interop -Scenarios for `MetadataLoadContext` include design-time features, build-time tooling, and runtime light-up features that need to inspect a set of assemblies as data and have all file locks and memory freed after inspection is performed. +Windows offers a rich native API in the form of flat C APIs, COM, and WinRT. While .NET Core supports **P/Invoke**, .NET Core 3.0 adds the ability to **CoCreate COM APIs** and **Activate WinRT APIs**. For a code example, see the [Excel Demo](https://github.com/dotnet/samples/tree/master/core/extensions/ExcelDemo). -The `MetadataLoadContext` has a resolver class passed to its constructor. The resolver's job is to load an `Assembly` given its `AssemblyName`. The resolver class derives from the abstract `MetadataAssemblyResolver` class. An implementation of the resolver for path-based scenarios is provided with `PathAssemblyResolver`. -The [MetadataLoadContext tests](https://github.com/dotnet/corefx/tree/master/src/System.Reflection.MetadataLoadContext/tests/src/Tests) demonstrate many use cases. The [Assembly tests](https://github.com/dotnet/corefx/blob/master/src/System.Reflection.MetadataLoadContext/tests/src/Tests/Assembly/AssemblyTests.cs) are a good place to start. ## TLS 1.3 & OpenSSL 1.1.1 on Linux -.NET Core will now take advantage of [TLS 1.3 support in OpenSSL 1.1.1](https://www.openssl.org/blog/blog/2018/09/11/release111/), when it is available in a given environment. There are multiple benefits of TLS 1.3, per the [OpenSSL team](https://www.openssl.org/blog/blog/2018/09/11/release111/): - -* Improved connection times due to a reduction in the number of round trips required between the client and server. +.NET Core now takes advantage of [TLS 1.3 support in OpenSSL 1.1.1](https://www.openssl.org/blog/blog/2018/09/11/release111/), when it's available in a given environment. With TLS 1.3: -* Improved security due to the removal of various obsolete and insecure cryptographic algorithms and encryption of more of the connection handshake. +* Connection times are improved with reduced round trips required between the client and server. +* Improved security because of the removal of various obsolete and insecure cryptographic algorithms. -.NET Core 3.0 Preview 1 is capable of utilizing **OpenSSL 1.1.1**, **OpenSSL 1.1.0**, or **OpenSSL 1.0.2** (whatever the best version found is, on a Linux system). When **OpenSSL 1.1.1** is available the SslStream and HttpClient types will use **TLS 1.3** when using `SslProtocols.None` (system default protocols), assuming both the client and server support **TLS 1.3**. - -The following sample demonstrates .NET Core 3.0 Preview 1 on Ubuntu 18.10 connecting to : - -```csharp -using System; -using System.Net.Security; -using System.Net.Sockets; -using System.Threading.Tasks; - -namespace tlstest -{ - class Program - { - static async Task Main() - { - using (TcpClient tcpClient = new TcpClient()) - { - string targetHost = "www.cloudflare.com"; - - await tcpClient.ConnectAsync(targetHost, 443); - - using (SslStream sslStream = new SslStream(tcpClient.GetStream())) - { - await sslStream.AuthenticateAsClientAsync(targetHost); - await Console.Out.WriteLineAsync($"Connected to {targetHost} with {sslStream.SslProtocol}"); - } - } - } - } -} -``` - -```console -user@comp-ubuntu1810:~/tlstest$ dotnet run -Connected to www.cloudflare.com with Tls13 -user@comp-ubuntu1810:~/tlstest$ openssl version -OpenSSL 1.1.1 11 Sep 2018 -``` +When available, .NET Core 3.0 uses **OpenSSL 1.1.1**, **OpenSSL 1.1.0**, or **OpenSSL 1.0.2** on a Linux system. When **OpenSSL 1.1.1** is available, both and types will use **TLS 1.3** (assuming both the client and server support **TLS 1.3**). >[!IMPORTANT] >Windows and macOS do not yet support **TLS 1.3**. .NET Core 3.0 will support **TLS 1.3** on these operating systems when support becomes available. -## Cryptography +The following C# 8.0 example demonstrates .NET Core 3.0 on Ubuntu 18.10 connecting to : -Support has been added for **AES-GCM** and **AES-CCM** ciphers, implemented via `System.Security.Cryptography.AesGcm` and `System.Security.Cryptography.AesCcm`. These algorithms are both [Authenticated Encryption with Association Data (AEAD) algorithms](https://en.wikipedia.org/wiki/Authenticated_encryption), and the first Authenticated Encryption (AE) algorithms added to .NET Core. +[!CODE-csharp[TLSExample](~/samples/core/whats-new/whats-new-in-30/cs/TLS.cs#TLS)] -The following code demonstrates using **AesGcm** cipher to encrypt and decrypt random data. -The code for **AesCcm** would look almost identical (only the class variable names would be different). -```csharp -// key should be: pre-known, derived, or transported via another channel, such as RSA encryption -byte[] key = new byte[16]; -RandomNumberGenerator.Fill(key); +## Cryptography ciphers -byte[] nonce = new byte[12]; -RandomNumberGenerator.Fill(nonce); +.NET 3.0 adds support for **AES-GCM** and **AES-CCM** ciphers, implemented with and respectively. These algorithms are both [Authenticated Encryption with Association Data (AEAD) algorithms](https://en.wikipedia.org/wiki/Authenticated_encryption). -// normally this would be your data -byte[] dataToEncrypt = new byte[1234]; -byte[] associatedData = new byte[333]; -RandomNumberGenerator.Fill(dataToEncrypt); -RandomNumberGenerator.Fill(associatedData); +The following code demonstrates using `AesGcm` cipher to encrypt and decrypt random data. -// these will be filled during the encryption -byte[] tag = new byte[16]; -byte[] ciphertext = new byte[dataToEncrypt.Length]; +[!CODE-csharp[AesGcm](~/samples/core/whats-new/whats-new-in-30/cs/Cipher.cs#AesGcm)] -using (AesGcm aesGcm = new AesGcm(key)) -{ - aesGcm.Encrypt(nonce, dataToEncrypt, ciphertext, tag, associatedData); -} -// tag, nonce, ciphertext, associatedData should be sent to the other part - -byte[] decryptedData = new byte[ciphertext.Length]; - -using (AesGcm aesGcm = new AesGcm(key)) -{ - aesGcm.Decrypt(nonce, ciphertext, tag, decryptedData, associatedData); -} - -// do something with the data -// this should always print that data is the same -Console.WriteLine($"AES-GCM: Decrypted data is{(dataToEncrypt.SequenceEqual(decryptedData) ? "the same as" : "different than")} original data."); -``` ## Cryptographic Key Import/Export -.NET Core 3.0 Preview 1 supports the import and export of asymmetric public and private keys from standard formats, without needing to use an X.509 certificate. - -All key types (RSA, DSA, ECDsa, ECDiffieHellman) support the **X.509 SubjectPublicKeyInfo** format for public keys, and the **PKCS#8 PrivateKeyInfo** and **PKCS#8 EncryptedPrivateKeyInfo** formats for private keys. RSA additionally supports **PKCS#1 RSAPublicKey** and **PKCS#1 RSAPrivateKey**. The export methods all produce DER-encoded binary data, and the import methods expect the same. If a key is stored in the text-friendly PEM format, the caller will need to base64-decode the content before calling an import method. - -```csharp -using System; -using System.IO; -using System.Security.Cryptography; - -namespace rsakeyprint -{ - class Program - { - static void Main(string[] args) - { - using (RSA rsa = RSA.Create()) - { - byte[] keyBytes = File.ReadAllBytes(args[0]); - rsa.ImportRSAPrivateKey(keyBytes, out int bytesRead); - - Console.WriteLine($"Read {bytesRead} bytes, {keyBytes.Length-bytesRead} extra byte(s) in file."); - RSAParameters rsaParameters = rsa.ExportParameters(true); - Console.WriteLine(BitConverter.ToString(rsaParameters.D)); - } - } - } -} -``` - -```console -user@comp-ubuntu1810:~/rsakeyprint$ echo Making a small key to save on screen space. -Making a small key to save on screen space. -user@comp-ubuntu1810:~/rsakeyprint$ openssl genrsa 768 | openssl rsa -outform der -out rsa.key -Generating RSA private key, 768 bit long modulus (2 primes) -..+++++++ -........+++++++ -e is 65537 (0x010001) -writing RSA key -user@comp-ubuntu1810:~/rsakeyprint$ dotnet run rsa.key -Read 461 bytes, 0 extra byte(s) in file. -0F-D0-82-34-F8-13-38-4A-7F-C7-52-4A-F6-93-F8-FB-6D-98-7A-6A-04-3B-BC-35-8C-7D-AC-A5-A3-6E-AD-C1-66-30-81-2C-2A-DE-DA-60-03-6A-2C-D9-76-15-7F-61-97-57- -79-E1-6E-45-62-C3-83-04-97-CB-32-EF-C5-17-5F-99-60-92-AE-B6-34-6F-30-06-03-AC-BF-15-24-43-84-EB-83-60-EF-4D-3B-BD-D9-5D-56-26-F0-51-CE-F1 -user@comp-ubuntu1810:~/rsakeyprint$ openssl rsa -in rsa.key -inform der -text -noout | grep -A7 private -privateExponent: - 0f:d0:82:34:f8:13:38:4a:7f:c7:52:4a:f6:93:f8: - fb:6d:98:7a:6a:04:3b:bc:35:8c:7d:ac:a5:a3:6e: - ad:c1:66:30:81:2c:2a:de:da:60:03:6a:2c:d9:76: - 15:7f:61:97:57:79:e1:6e:45:62:c3:83:04:97:cb: - 32:ef:c5:17:5f:99:60:92:ae:b6:34:6f:30:06:03: - ac:bf:15:24:43:84:eb:83:60:ef:4d:3b:bd:d9:5d: - 56:26:f0:51:ce:f1 -``` - -PKCS#8 files can be inspected with the `System.Security.Cryptography.Pkcs.Pkcs8PrivateKeyInfo` class. +.NET Core 3.0 supports the import and export of asymmetric public and private keys from standard formats. You don't need to use an X.509 certificate. -PFX/PKCS#12 files can be inspected and manipulated with `System.Security.Cryptography.Pkcs.Pkcs12Info` and `System.Security.Cryptography.Pkcs.Pkcs12Builder`, respectively. +All key types, such as *RSA*, *DSA*, *ECDsa*, and *ECDiffieHellman*, support the following formats: -## SerialPort for Linux +* **Public Key** + * X.509 SubjectPublicKeyInfo -.NET Core 3.0 now supports on Linux. +* **Private key** + * PKCS#8 PrivateKeyInfo + * PKCS#8 EncryptedPrivateKeyInfo -Previously, .NET Core only supported using the `SerialPort` type on Windows. +RSA keys also support: -## More BCL Improvements +* **Public Key** + * PKCS#1 RSAPublicKey -The `Span`, `Memory`, and related types that were introduced in .NET Core 2.1, have been optimized in .NET Core 3.0. Common operations such as span construction, slicing, parsing, and formatting now perform better. +* **Private key** + * PKCS#1 RSAPrivateKey -Additionally, types like `String` have seen under-the-cover improvements to make them more efficient when used as keys with `Dictionary` and other collections. No code changes are required to benefit from these improvements. +The export methods produce DER-encoded binary data, and the import methods expect the same. If a key is stored in the text-friendly PEM format, the caller will need to base64-decode the content before calling an import method. -The following improvements are also new in .NET Core 3 Preview 1: +[!CODE-csharp[RSA](~/samples/core/whats-new/whats-new-in-30/cs/RSA.cs#Rsa)] -* Brotli support built in to HttpClient -* ThreadPool.UnsafeQueueWorkItem(IThreadPoolWorkItem) -* Unsafe.Unbox -* CancellationToken.Unregister -* Complex arithmetic operators -* Socket APIs for TCP keep alive -* StringBuilder.GetChunks -* IPEndPoint parsing -* RandomNumberGenerator.GetInt32 +**PKCS#8** files can be inspected with and **PFX/PKCS#12** files can be inspected with . **PFX/PKCS#12** files can be manipulated with . -## Tiered compilation -[Tiered compilation](https://devblogs.microsoft.com/dotnet/tiered-compilation-preview-in-net-core-2-1/) is on by default with .NET Core 3.0. It is a feature that enables the runtime to more adaptively use the Just-In-Time (JIT) compiler to get better performance, both at startup and to maximize throughput. -This feature was added as an opt-in feature in [.NET Core 2.1](https://devblogs.microsoft.com/dotnet/announcing-net-core-2-1/) and then was enabled by default in [.NET Core 2.2 Preview 2](https://devblogs.microsoft.com/dotnet/announcing-net-core-2-2-preview-2/). Subsequently, it has been reverted back to opt in with the .NET Core 2.2 release. - -## ARM64 Linux support - -Support has been added for ARM64 for Linux. The primary use case for ARM64 is currently with IoT scenarios. - -Alpine, Debian and Ubuntu [Docker images are available for .NET Core for ARM64](https://hub.docker.com/r/microsoft/dotnet/). +## SerialPort for Linux -Please check [.NET Core ARM64 Status](https://github.com/dotnet/announcements/issues/82) for more information. +.NET Core 3.0 supports on Linux. ->[!NOTE] -> **ARM64** Windows support isn't yet available. +Previously, .NET Core only supported using `SerialPort` on Windows. -## Install .NET Core 3.0 Previews on Linux with Snap -Snap is the preferred way to install and try .NET Core previews on [Linux distributions that support Snap](https://docs.snapcraft.io/installing-snapd/6735). -After configuring Snap on your system, run the following command to install the [.NET Core SDK 3.0 Preview SDK](https://snapcraft.io/dotnet-sdk). +## Docker and cgroup memory Limits -```console -sudo snap install dotnet-sdk --beta --classic -``` +Starting with Preview 3, running .NET Core 3.0 on Linux with Docker works better with cgroup memory limits. Running a Docker container with memory limits, such as with `docker run -m`, changes how .NET Core behaves. -When .NET Core in installed using the Snap package, the default .NET Core command is `dotnet-sdk.dotnet`, as opposed to just `dotnet`. The benefit of the namespaced command is that it will not conflict with a globally installed .NET Core version you may have. This command can be aliased to `dotnet` with: +* Default Garbage Collector (GC) heap size: maximum of 20 mb or 75% of the memory limit on the container. +* Explicit size can be set as an absolute number or percentage of cgroup limit. +* Minimum reserved segment size per GC heap is 16 mb. This size reduces the number of heaps that are created on machines. -```console -sudo snap alias dotnet-sdk.dotnet dotnet -``` -Some distros require an additional step to enable access to the SSL certificate. See our [Linux Setup](https://github.com/dotnet/core/blob/master/Documentation/linux-setup.md) for details. ## GPIO Support for Raspberry Pi -Two new packages have been released to NuGet that you can use for GPIO programming. - -* [System.Device.Gpio](https://www.nuget.org/packages/System.Device.Gpio/0.1.0-prerelease.19078.2) -* [Iot.Device.Bindings](https://www.nuget.org/packages/Iot.Device.Bindings/0.1.0-prerelease.19078.2) +Two packages have been released to NuGet that you can use for GPIO programming: -The GPIO Packages includes APIs for GPIO, SPI, I2C and PWM devices. The IoT bindings package includes [device bindings](https://github.com/dotnet/iot/blob/master/src/devices/README.md) for various chips and sensors, the same ones available at [dotnet/iot - src/devices](https://github.com/dotnet/iot/tree/master/src/devices). +* [System.Device.Gpio](https://www.nuget.org/packages/System.Device.Gpio) +* [Iot.Device.Bindings](https://www.nuget.org/packages/Iot.Device.Bindings) -The updated serial port APIs that were announced as part of .NET Core 3.0 Preview 1 are not part of these packages but are available as part of the .NET Core platform. +The GPIO packages include APIs for *GPIO*, *SPI*, *I2C*, and *PWM* devices. The IoT bindings package includes device bindings. For more information, see the [devices GitHub repo](https://github.com/dotnet/iot/blob/master/src/devices/). -## Platform Support -.NET Core 3 will be supported on the following operating systems: -* Windows Client: 7, 8.1, 10 (1607+) -* Windows Server: 2012 R2 SP1+ -* macOS: 10.12+ -* RHEL: 6+ -* Fedora: 26+ -* Ubuntu: 16.04+ -* Debian: 9+ -* SLES: 12+ -* openSUSE: 42.3+ -* Alpine: 3.8+ - -Chip support follows: +## ARM64 Linux support -* x64 on Windows, macOS, and Linux -* x86 on Windows -* ARM32 on Windows and Linux -* ARM64 on Linux +.NET Core 3.0 adds support for ARM64 for Linux. The primary use case for ARM64 is currently with IoT scenarios. For more information, see [.NET Core ARM64 Status](https://github.com/dotnet/announcements/issues/82). -For Linux, ARM32 is supported on Debian 9+ and Ubuntu 16.04+. For ARM64, it is the same as ARM32 with the addition of Alpine 3.8. These are the same versions of those distros as is supported for X64. +[Docker images for .NET Core on ARM64](https://hub.docker.com/r/microsoft/dotnet/) are available for Alpine, Debian, and Ubuntu. -Docker images for .NET Core 3.0 are available at [microsoft/dotnet on Docker Hub](https://hub.docker.com/r/microsoft/dotnet/). Microsoft is currently in the process of adopting [Microsoft Container Registry (MCR)](https://cloudblogs.microsoft.com/opensource/2019/01/17/improved-discovery-experience-microsoft-containers-docker-hub/) and it is expected that the final .NET Core 3.0 images will only be published to MCR. +> [!NOTE] +> **ARM64** Windows support isn't yet available.