[翻译].NET Core 3 Preview1和Windows桌面框架开源
原文来自TechViews
今天,我们宣布推出.NET Core 3 Preview 1.这是.NET Core 3的第一个公开发布。我们有一些令人兴奋的新功能可供分享,并希望得到您的反馈。您可以使用Visual Studio 2019 Preview 1,Visual Studio for Mac和Visual Studio Code开发.NET Core 3应用程序。
立即在Windows,Mac和Linux上下载并开始使用.NET Core 3 Preview 1 。
您可以在.NET Core 3 Preview 1发行说明中查看该发行版的完整详细信息。 请在评论或 dotnet / core#2099中 报告您发现的任何问题 。
Visual Studio 2019将是支持构建.NET Core 3应用程序的版本, 今天也发布了预览版,因此我们也鼓励您查看它。
.NET Core 3是一项重大更新,它增加了对使用Windows Presentation Foundation(WPF),Windows窗体和Entity Framework 6(EF6)构建Windows桌面应用程序的支持。 ASP.NET Core 3支持使用Razor组件进行客户端开发。 EF Core 3将支持Azure Cosmos DB。它还将包括对C#8和.NET Standard 2.1的支持等等!
.NET Framework 4.8
在深入研究.NET Core 3之前,我们先来看看.NET Framework。明年我们将发布.NET Framework 4.8。随着支持4K和8K分辨率的显示器,我们正在为WPF和Windows Forms的高DPI添加更好的支持。许多.NET应用程序使用基于旧版Internet Explorer和Windows Media Player的浏览器和媒体控件。我们正在添加使用Windows 10中最新浏览器和媒体播放器的新控件,并支持最新标准。 WPF和Windows Forms应用程序可以通过XAML Islands访问Windows UI XAML库(WinUI),以获得现代外观和触摸支持。 Visual Studio 2019基于.NET Framework并使用了许多这些功能。有关.NET Framework 4.8的更多信息,请参阅我们的帖子: .NET Core 3.0和.NET Framework 4.8上的更新 。
Windows桌面来自.NET Core
.NET Core的前两个版本主要侧重于支持Web应用程序,Web API,IoT和控制台应用程序。 .NET Core 3增加了对使用WPF和Windows Forms框架以及现代控件构建Windows桌面应用程序的支持,以及通过XAML Islands从Windows UI XAML库(WinUI)构建的Fluent样式。
今天许多桌面应用程序使用Entity Framework进行数据访问,因此我们也支持.NET Core 3上的Entity Framework 6。这些框架使开发人员能够构建Windows桌面应用程序,以利用.NET Core中的新功能,例如并行部署,自包含应用程序(在应用程序内部运行.NET Core),CoreFX的最新改进等。
WPF,Windows窗体和WinUI Open Sourced
2014年11月12日,我们宣布了.NET Core的开源。它取得了巨大的成功。 .NET平台已经收到来自微软以外的3700多家公司的超过60,000个社区接受的拉取请求。
今天,我们很高兴地宣布开源WPF , Windows Forms和WinUI ,因此三种主要的Windows UX技术将是开源的。有史以来第一次,社区将能够看到WPF,Windows Forms和WinUI的开发在公开场合发生,我们将在.NET Core上为这些框架做出贡献。第一波代码将于今天在GitHub上发布,未来几个月将出现更多代码。
WPF和Windows Forms项目由.NET基金会管理,该基金会今天也宣布了更改,以便社区直接指导基础运营。它还通过欢迎Pivotal,Progress Telerik和Insight来扩大目前的赞助商 - 红帽,JetBrains,谷歌,Unity,微软和三星。这种新结构将有助于.NET Foundation扩展以满足不断增长的.NET开源生态系统的需求。
真的是成为.NET开发人员的激动人心的时刻!
WPF和Windows窗体
WPF和Windows窗体现在可以与.NET Core一起使用。它们出现在一个名为“Windows桌面”的新组件中,该组件是Windows版本的SDK的一部分。
我们一直在与社区开发人员合作,他们已经在早期版本的.NET Core 3上运行他们的Windows桌面应用程序。他们给了我们很好的反馈,WPF和Windows Forms API兼容并且他们已经成功!
- .NET Core 3入门 - 创建WPF应用程序
- Greenshot成为了dotnet的核心! - 推特
- NuGet Package Explorer v5,已经是.NET Core 3 WPF应用程序
- 使用Desktop Bridge打包.NET Core应用程序
- Hello .NET与MahApps.Metro一起使用
- NETworkManager .NET核心端口
您可以从命令行为WPF和Windows窗体创建新的.NET Core项目。
dotnet new wpf dotnet new winforms
创建项目后,您可以运行它们。下图说明了新的WPF应用程序的外观。
Windows窗体非常相似,如下图所示。
您还可以在Visual Studio 2019 Preview 1中打开,启动和调试WPF和Windows窗体项目。目前可以在Visual Studio 2017 15.9中打开.NET Core 3.0项目,但是,它不是受支持的场景(并且您需要启用预览 )。
新项目与现有的.NET Core项目相同,只增加了几个。以下是基本.NET Core控制台项目与基本Windows窗体和WPF项目的比较。
在.NET Core控制台项目中,该文件使用Microsoft.NET.Sdk
SDK并通过netcoreapp3.0
目标框架声明对.NET Core 3.0的依赖:
WPF和Windows窗体项目看起来很相似,但使用不同的SDK并使用属性来声明正在使用的UI框架:
对于WPF:
对于Windows窗体:
该UseWPF
和UseWindowsForms
属性允许一个项目,指定是否使用Windows窗体或WPF。这将允许工具(例如Intellisense,或Visual Studio中的工具箱或菜单)提供针对所使用的UI框架定制的体验。如果应用程序同时使用两个框架,则两个属性都可以设置为true,例如,当Windows窗体对话框承载WPF控件时。
在接下来的几个月中,我们将重点关注完成WPF和Windows Forms的开源,使Visual Studio设计人员能够使用.NET Core,并添加对Windows桌面应用程序中常用的API的支持。请分享您对dotnet / winforms , dotnet / wpf和dotnet / core repos的反馈。
应用程序现在默认具有可执行文件
.NET Core应用程序现在使用可执行文件构建。这对于使用全局安装的.NET Core版本的应用程序来说是新的。到目前为止,只有自包含的应用程序具有可执行文件。您可以看到以下示例中生成的可执行文件。
对于这些可执行文件,您可以期望与其他本机可执行文件相同的内容,例如:
- 您可以双击可执行文件。
- 您可以在不使用dotnet工具的情况下从命令提示符启动应用程序,在Windows上使用
./myconsole
,在Linux和macOS上使用myconsole.exe
,如以下示例所示。
在Windows上:
C:Usersrlandermyconsole>dotnet build C:Usersrlandermyconsole>cd binDebugnetcoreapp3.0 C:UsersrlandermyconsolebinDebugnetcoreapp3.0>dir /b myconsole.deps.json myconsole.dll myconsole.exe myconsole.pdb myconsole.runtimeconfig.dev.json myconsole.runtimeconfig.json C:UsersrlandermyconsolebinDebugnetcoreapp3.0>myconsole.exe Hello World! C:UsersrlandermyconsolebinDebugnetcoreapp3.0>dotnet myconsole.dll Hello World!
在Linux上(和macOS类似):
root@cc08212a1da6:/myconsole # dotnet build root@cc08212a1da6:/myconsole # cd bin/Debug/netcoreapp3.0/ root@cc08212a1da6:/myconsole/bin/Debug/netcoreapp3.0 # ls myconsole myconsole.dll myconsole.runtimeconfig.dev.json myconsole.deps.json myconsole.pdb myconsole.runtimeconfig.json root@cc08212a1da6:/myconsole/bin/Debug/netcoreapp3.0 # ./myconsole Hello World! root@cc08212a1da6:/myconsole/bin/Debug/netcoreapp3.0 # dotnet myconsole.dll Hello World!
提供的可执行文件与您正在使用的SDK的环境相匹配。我们还没有为其他运行时环境启用-r
参数。
dotnet build现在复制依赖项
dotnet build现在可以在构建操作期间将NuGet缓存中的NuGet依赖项从NuGet缓存复制到构建输出文件夹。在此版本之前,这些依赖项仅作为dotnet发布的一部分进行复制。此更改允许您将构建输出xcopy到不同的计算机。
有一些操作,如链接和剃刀页面发布仍然需要发布。
您可以在以下示例中看到新体验:
C:Usersrlandermyconsole>dotnet add package Newtonsoft.json C:Usersrlandermyconsole>dotnet build C:Usersrlandermyconsole>dir /b binDebugnetcoreapp3.0*.dll myconsole.dll Newtonsoft.Json.dll
本地dotnet工具
.NET Core工具已更新为包含本地工具方案。我们在.NET Core 2.1中添加了全局工具 。可以从机器上的任何位置为当前用户提供全局工具。这很好,但是这不允许每个位置选择版本(通常是每个存储库),并且它们不提供简单的方法来恢复开发或构建工具环境。磁盘上的特定位置现在可以与一组本地工具及其版本相关联。本地工具依赖于名为dotnet-tools.json
的工具清单文件。我们建议在存储库的根目录中提供工具清单文件。
本地工具具有将全局工具添加到工具清单文件(通常是存储库)并克隆包含它们的存储库的不同体验。如果克隆包含本地工具的repo,则只需运行以下命令:
dotnet tool restore
恢复后,您可以使用以下命令调用本地工具:
dotnet tool run <toolCommandName>
调用本地工具时,dotnet会搜索目录结构的清单。找到工具清单文件后,将搜索所请求的工具。如果找到该工具,它将包含在NuGet全局包位置中查找工具所需的信息。工具清单文件中的工具的正确版本在还原时放置在缓存中。
如果在清单中找到该工具,但在缓存中找不到该工具,则用户会收到错误。预览1后,该消息将得到改进,以请求用户运行dotnet tool restore
。
要将本地工具添加到目录,您需要首先创建工具清单文件。在预览1之后,我们将提供一种机制来创建工具清单文件,可能是通过dotnet新模板。对于预览1,您必须使用以下内容创建文件名dotnet-tools.json:
创建清单后,您可以使用以下方法向其添加本地工具:
dotnet tool install <toolPackageId>
除非指定了其他版本,否则此命令将安装最新版本的工具。此版本将写入工具清单文件,以允许调用正确的工具版本。工具清单文件旨在允许手动编辑 - 您可以执行此操作来更新使用存储库所需的版本。示例dotnet-tools.json
文件如下:
要从工具清单文件中删除工具,请运行以下命令:
dotnet tool uninstall <toolPackageId>
如果将工具清单文件签入到源代码管理中,则克隆代理的程序员可以访问正确的工具,如上所述。
对于全局和本地工具,都需要兼容的运行时版本。目前NuGet.org上的许多工具都面向.NET Core Runtime 2.1。如果只安装.NET Core 3.0的预览版,则可能还需要手动安装.NET Core 2.1 Runtime 。
有关更多信息,请参阅本地工具早期预览文档 。
推出快速收件箱JSON阅读器
System.Text.Json.Utf8JsonReader
是一个高性能,低分配,仅向前读取器,用于UTF-8编码的JSON文本,从ReadOnlySpan<byte>
读取。 Utf8JsonReader
是一种基础的低级类型,可用于构建自定义解析器和反序列化器。使用新的Utf8JsonReader
读取JSON有效负载比使用Json.NET中的读取器快2倍。在您需要将JSON令牌实现为(UTF16)字符串之前,它不会分配。
此新API将包含以下组件:
- 预览1:JSON阅读器(顺序访问)
- 下一步:JSON编写器,DOM(随机访问),poco序列化器,poco反序列化器
这是Utf8JsonReader
的基本读者循环,可以作为起点:
.NET生态系统依赖于Json.NET和其他流行的JSON库,这些库仍然是不错的选择。 JSON.NET使用.NET字符串作为其基本数据类型,它是引擎盖下的UTF16。在.NET Core 2.1和3.0中,我们添加了新的API,可以根据使用Span<T>
和UTF8字符串编写需要更少内存的JSON API,并更好地满足Kestrel等高吞吐量应用程序的需求, ASP.NET核心Web服务器。这就是我们用Utf8JsonReader所做的。
您可能想知道为什么我们不能只更新Json.NET以包含使用Span<T>
解析JSON的支持? James Newton- King-- Json.NET的作者 - 对此有以下说法:
Json.NET是在10多年前创建的,从那以后它增加了一系列功能,旨在帮助开发人员在.NET中使用JSON。在那个时候,Json.NET也成为了NuGet最依赖和下载的软件包,并且是.NET中JSON支持的首选库。不幸的是,Json.NET的丰富功能和受欢迎程度不利于对其进行重大更改。支持像Span这样的新技术需要对库进行根本性的重大更改,并且会破坏依赖于它的现有应用程序和库。
展望未来Json.NET将继续致力于并投资,既解决了今天的已知问题,也支持未来的新平台。 Json.NET一直存在于.NET的其他JSON库中,并且没有什么可以阻止您一起使用一个或多个,这取决于您是需要新JSON API的性能还是Json.NET的大型功能集。
有关更多信息,请参阅dotnet / corefx#33115和System.Text.Json路线图 。
范围和指数
我们正在添加一个类型Index
,可用于索引。您可以从一个从头开始计数的int
创建一个,或者从末尾开始计算前缀^
运算符:
我们还引入了一个Range
类型,它由两个Index
值组成,一个用于开始,一个用于结束,并且可以用x..y
范围表达式编写。然后,您可以使用Range进行索引以生成切片:
注意:此功能也是C#8的一部分。
异步流
我们介绍IAsyncEnumerable<T>
,这正是您所期望的; IEnumerable<T>
的异步版本。该语言允许您等待foreach以消耗它们的元素,并返回它们以生成元素。
以下示例演示了异步流的生成和使用。 foreach语句是异步的,它本身使用yield return
为调用者生成异步流。这种模式 - 使用yield return
- 是生成异步流的推荐模型。
除了能够await foreach
,您还可以创建异步迭代器,例如,返回IAsyncEnumerable/IAsyncEnumerator
的迭代器,您可以await
和yield
。对于需要处理的对象,可以使用IAsyncDisposable
,其中包含各种BCL类型实现,例如Stream
和Timer
。
注意:此功能也是C#8的一部分。
System.Buffers.SequenceReader
我们添加了System.Buffers.SequenceReader
作为ReadOnlySequence<T>
的阅读器。这允许简单,高性能,低分配解析可以跨越多个后备缓冲区的System.IO.Pipelines
数据。以下示例将输入Sequence
分解为有效的CR / LF分隔行:
Linux上现在支持串行端口API
串口可能看起来像是你多年未在机器上看到的旧外围设备。它不是笔记本电脑和台式机上常用或可用的端口,但它对物联网(IoT)解决方案至关重要。我们现在支持Linux上的串行端口。到目前为止,支持仅限于Windows。
在过去的几个月里,我们一直在与物联网开发人员讨论这种能力。其中一个具体要求是从Raspberry Pi与Arduino进行通信。 以下示例演示了该方案。
我们还致力于使用.NET Core API从Raspberry Pi中刷新Arduino。我们收到了开发人员的要求,他们希望使用RS-485等特定标准以及MODBUS , CANBUS和ccTalk等协议。请告诉我们您的应用场景需要哪些协议。
现在提供GPIO,PWM,SPI和I2C API
物联网设备暴露的不仅仅是串行端口。它们通常会暴露多种引脚 ,可以通过编程方式读取传感器,驱动LED / LCD / eInk显示器并与我们的设备进行通信。 .NET Core现在具有GPIO , PWM , SPI和I²C引脚类型的API。
这些API可通过System.Device.GPIO NuGet包获得 。 .NET Core 2.1及更高版本将支持它。
上一节显示了使用引脚8和10(分别为TX和RX)与Arduino进行通信的覆盆子Pi,用于串行端口通信。这是以编程方式编程这些引脚的一个例子。
下图演示了如何将文本打印到LCD面板。
您可以看到使用.NET Core构建物联网设备的“开发人员安装”是什么样的。
这些包是从dotnet / iot repo构建的。 repo还包括样本和设备绑定 。我们希望社区将通过提供样本和设备绑定来加入我们。我们注意到Python社区有一组丰富的样本和绑定,特别是AdaFruit提供的 。事实上,我们将一些样本(允许许可证)移植到C#。我们希望随着时间的推移为.NET开发人员提供类似的丰富的示例和绑定。
我们的大部分努力都花在支持Raspberry Pi 3中的这些API上。我们计划支持其他设备,如Hummingboard 。请告诉我们哪些板对您很重要。我们正在Raspberry Pi Zero上测试Mono 。
现在支持Linux上支持TLS 1.3和OpenSSL 1.1.1
.NET Core现在将在OpenSSL 1.1.1中利用TLS 1.3支持 ,当它在给定环境中可用时。根据OpenSSL团队 ,TLS 1.3有多种好处:
- 由于减少了客户端和服务器之间所需的往返次数,缩短了连接时间
- 由于删除了各种过时和不安全的加密算法以及更多连接握手的加密,提高了安全性
.NET Core 3.0 Preview 1能够使用OpenSSL 1.1.1,OpenSSL 1.1.0或OpenSSL 1.0.2(无论在Linux系统上找到的最佳版本)。当OpenSSL 1.1.1可用时,SslStream和HttpClient类型在使用SslProtocols.None(系统默认协议)时将使用TLS 1.3,假设客户端和服务器都支持TLS 1.3。
以下示例演示了连接到https://www.cloudflare.com的 Ubuntu 18.10上的.NET Core 3.0 Preview 1:
jbarton@jsb-ubuntu1810:~/tlstest $ cat Program.cs 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}");
}
}
}
}
}
jbarton@jsb-ubuntu1810:~/tlstest $ dotnet run
Connected to www.cloudflare.com with Tls13
jbarton@jsb-ubuntu1810:~/tlstest $ openssl version
OpenSSL 1.1.1 11 Sep 2018
注意:Windows和macOS尚不支持TLS 1.3。 .NET Core将在这些操作系统上支持TLS 1.3 - 我们希望在支持可用时自动支持。
加密
我们添加了对AES-GCM和AES-CCM密码的支持,这些密码通过System.Security.Cryptography.AesGcm
和System.Security.Cryptography.AesCcm
。这些算法都是带有关联数据的身份验证加密(AEAD)算法 ,以及添加到.NET Core的第一个经过身份验证的加密(AE)算法。
以下代码演示了使用AesGcm密码加密和解密随机数据。 AesCcm的代码看起来几乎相同(只有类变量名称会有所不同)。
// key should be: pre-known, derived, or transported via another channel, such as RSA encryption
byte [] key = new byte [ 16 ];
RandomNumberGenerator . Fill ( key );byte [] nonce = new byte [ 12 ];
RandomNumberGenerator . Fill ( nonce );// normally this would be your data
byte [] dataToEncrypt = new byte [ 1234 ];
byte [] associatedData = new byte [ 333 ];
RandomNumberGenerator . Fill ( dataToEncrypt );
RandomNumberGenerator . Fill ( associatedData );// these will be filled during the encryption
byte [] tag = new byte [ 16 ];
byte [] ciphertext = new byte [ dataToEncrypt . Length ];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. " );
加密密钥导入/导出
.NET Core 3.0 Preview 1现在支持从标准格式导入和导出非对称公钥和私钥,而无需使用X.509证书。
所有密钥类型(RSA,DSA,ECDsa,ECDiffieHellman)都支持公钥的X.509 SubjectPublicKeyInfo格式,以及私钥的PKCS#8 PrivateKeyInfo和PKCS#8 EncryptedPrivateKeyInfo格式。 RSA还支持PKCS#1 RSAPublicKey和PKCS#1 RSAPrivateKey。导出方法都生成DER编码的二进制数据,导入方法期望相同;如果密钥以文本友好的PEM格式存储,则调用者需要在调用导入方法之前对内容进行base64解码。
jbarton@jsb-ubuntu1810:~/rsakeyprint $ cat Program.cs
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));
}
}
}
}
jbarton@jsb-ubuntu1810:~/rsakeyprint $ echo Making a small key to save on screen space.
Making a small key to save on screen space.
jbarton@jsb-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
jbarton@jsb-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
jbarton@jsb-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🇩🇪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
可以使用System.Security.Cryptography.Pkcs.Pkcs8PrivateKeyInfo
类检查PKCS#8文件。
可以分别使用System.Security.Cryptography.Pkcs.Pkcs12Info
和System.Security.Cryptography.Pkcs.Pkcs12Builder
检查和操作PFX / PKCS#12文件。
更多BCL改进
我们优化了Span<T>
, Memory<T>
以及.NET Core 2.1中引入的相关类型。跨度构造,切片,解析和格式化等常用操作现在表现更好。此外,像String这样的类型在使用Dictionary<TKey, TValue>
和其他集合作为键时,已经看到了封底改进,使它们更有效。无需更改代码即可享受这些改进。
以下改进也是.NET Core 3 Preview 1中的新增功能:
- Brotli支持内置于HttpClient
- ThreadPool.UnsafeQueueWorkItem(IThreadPoolWorkItem)
- Unsafe.Unbox
- CancellationToken.Unregister
- 复杂算术运算符
- TCP的套接字API保持活跃
- StringBuilder.GetChunks
- IPEndPoint解析
- RandomNumberGenerator.GetInt32
接口成员的默认实现
今天,一旦你发布了一个界面游戏结束:你不能在不破坏它的所有现有实施者的情况下添加成员。
在C#8.0中,我们让您为接口成员提供一个主体。因此,如果有人没有实现该成员(可能因为它们在编写代码时尚未实现),他们只会获得默认实现。
在这个例子中。 ConsoleLogger
类不必实现ILogger的Log(Exception)重载,因为它是使用默认实现声明的。现在,只要为现有实现者提供默认实现,就可以向现有公共接口添加新成员。
分层编译
默认情况下,使用.NET Core 3.0打开分层编译 。它是一项功能,使运行时能够更自适应地使用实时(JIT)编译器,以在启动时获得更好的性能并最大化吞吐量。它作为.NET Core 2.1中的选择加入功能添加,然后在.NET Core 2.2 Preview 2中默认启用。我们决定在最终的.NET Core 2.2版本中默认启用它,因此将其切换回选择加入,就像.NET Core 2.1一样。它在.NET Core 3.0中默认启用,我们希望它保留在该配置中。
使用MetadataLoadContext进行汇编元数据读取
我们添加了新的MetadataLoadContext类型,该类型可以在不影响调用者应用程序域的情况下读取程序集元数据。程序集作为数据读取,包括为不同的体系结构和平台构建的程序集,而不是当前的运行时环境。 MetadataLoadContext与ReflectionOnlyLoad类型重叠,后者仅在.NET Framework中可用。
System.Reflection.MetadataLoadContext包中提供了MetdataLoadContext。它是.NET Standard 2.0软件包。
MetadataLoadContext公开类似于AssemblyLoadContext类型的API,但不基于该类型。与AssemblyLoadContext非常相似,MetadataLoadContext允许在隔离的程序集加载Universe中加载程序集。 MetdataLoadContext API返回Assembly对象,允许使用熟悉的反射API。不允许使用面向执行的API,例如MethodBase.Invoke ,并将抛出InvalidOperationException。
以下示例演示如何在实现给定接口的程序集中查找具体类型:
MetadataLoadContext的方案包括设计时功能,构建时工具和运行时点亮功能,这些功能需要将一组程序集作为数据进行检查,并在执行检查后释放所有文件锁和内存。
MetadataLoadContext具有传递给其构造函数的解析程序类。解析器的工作是根据AssemblyName加载程序集。解析器类派生自抽象的MetadataAssemblyResolver类。 PathAssemblyResolver提供了基于路径的方案的解析器的实现。
MetadataLoadContext测试演示了许多用例。 大会测试是一个很好的起点。
注意:以下(现在很古老的)关于.NET程序集元数据的文章将从这个新API中受益: 使用MetaViewer在.NET EXE中显示元数据 。
ARM64
我们正在为此版本添加对ARM64 for Linux的支持。对于上下文,我们添加了对带有.NET Core 2.1的Linux的ARM32和带有.NET Core 2.2的Windows的支持。 ARM64的主要用例目前是IoT方案。我们正在使用的一些开发人员希望在ARM32环境和ARM64上的其他环境中部署。
Alpine,Debian和Ubuntu Docker镜像可用于.NET Core for ARM64 。
有关更多信息,请查看.NET Core ARM64状态 。
平台支持
以下操作系统将支持.NET Core 3:
- Windows客户端:7,8.1,10(1607+)
- Windows Server:20012 R2 SP1 +
- macOS:10.12+
- RHEL:6+
- Fedora:26岁以上
- Ubuntu:16.04+
- Debian:9+
- SLES:12+
- openSUSE:42.3+
- 高山:3.8+
芯片支持如下:
- Windows,macOS和Linux上的x64
- Windows上的x86
- Windows上的ARM32(附带预览版2)和Linux
- Linux上的ARM64
对于Linux,Debian 9+和Ubuntu 16.04+支持ARM32。对于ARM64,增加Alpine 3.8也是如此。这些是与X64支持的发行版相同的版本。我们有意识地决定在X64,ARM32和ARM64之间使支持的平台尽可能相似。
Docker Hub上的microsoft / dotnet提供了.NET Core 3.0的Docker镜像,包括ARM64。
摘要
我们很高兴能够在今天推出.NET Core 3的第一个预览版! .NET Core 3 Preview 1还包含.NET Core 2.2中的功能。您可以在此处阅读有关各种组件的更多信息:
我们将在未来几周内发布更多关于.NET Core 3的详细帖子,其中还将包括.NET Standard 2.1的更新,但尚未进入预览1。
要知道,如果您有现有的.NET Framework应用程序,那么就没有压力将它们移植到.NET Core。我们将向.NET Framework 4.8添加功能以支持新的桌面方案。虽然我们建议新的桌面应用程序应考虑针对.NET Core,但.NET Framework将保留高兼容性栏,并将在很长一段时间内为您的应用程序提供支持。使用.NET Core 3,我们将为希望利用.NET Core中的最新功能的应用程序提供出色的体验。