「翻译」.NET Core3.1发布

我们很高兴宣布.NET Core 3.1的发布。实际上,这只是对我们两个多月前发布的.NET Core 3.0的一小部分修复和完善。最重要的是.NET Core 3.1是长期支持(LTS)版本,并且将支持三年。和过去一样,我们希望花一些时间来发布下一个LTS版本。额外的两个月(在.NET Core 3.0之后)使我们能够选择和实施在已经非常稳定的基础上进行的正确改进。

您可以下载适用于Windows,macOS和Linux的.NET Core 3.1:

  • .NET Core 3.1 SDK和运行时
  • Docker容器映像
  • Snap安装程序
  • ASP.NET Core和EF Core也在今天发布。

Visual Studio 2019 16.4也于今天发布,其中包括.NET Core 3.1。这是将.NET Core 3.1与Visual Studio一起使用所必需的更新。对于Visual Studio 2019用户,我们建议仅将Visual Studio更新到16.4,而不是单独下载.NET Core 3.1。

Visual Studio for Mac在Visual Studio for Mac 8.4预览通道中还支持并包括.NET Core 3.1。您需要选择使用Preview通道才能使用.NET Core 3.1。

发行说明:

  • .NET Core 3.1发行说明
  • .NET Core 3.1问题的GitHub问题
  • GitHub发布

.NET Core 3.1中的更改??主要集中在Blazor和Windows Desktop,这是.NET Core 3.0中的两个新增功能。这包括对C++/ CLI的支持,这是针对Windows的开发人员的常规要求。

在我们了解.NET Core 3.1的新功能之前,让我们快速了解一下.NET Core 3.0的关键改进,这是.NET Core 3.1需要考虑的大部分重要内容。

.NET Core 3.0更新概述

.NET Core 3.0提供了以下关键改进。我们已经从从事大型网站的开发人员那里听说,它对他们来说运作得非常好。

  • .NET Core 3.0已经在dot.net和Bing.com上托管了几个月,已经通过了测试。其他许多Microsoft团队很快将在生产中的.NET Core 3.1上部署大型工作负载。
  • 性能有很大的提高跨许多部件,并在将详细描述在.NET Core 3.0性能改进和硬件内在函数在.NET Core。
  • C#8添加了异步流,范围/索引,更多模式和可为空的引用类型。Nullable使您可以直接针对导致的代码缺陷NullReferenceException。框架库的最底层已被注释,以便您知道何时可以期待null。
  • F#4.7致力于通过隐式yield表达式和一些语法放松使某些事情变得容易。它还包含对的支持LangVersion,并nameof在预览中附带并打开了静态类。F#核心库现在还针对.NET Standard 2.0。您可以在发布F#4.7中阅读更多内容。
  • .NET Standard 2.1增加了可以在.NET Core和Xamarin都可以使用的代码中使用的类型集。.NET Standard 2.1包括.NET Core 2.1以后的类型。
  • .NET Core现在支持Windows窗体和WPF(和开放源代码)的Windows桌面应用程序。WPF设计器是Visual Studio 2019的一部分。WindowsForms设计器处于预览状态,可以下载。
    现在,.NET Core应用程序默认情况下具有可执行文件。在过去的发行版中,需要通过dotnet命令来启动应用,例如dotnet myapp.dll。现在可以使用特定于应用程序的可执行文件(例如myapp或)启动应用程序./myapp,具体取决于操作系统。
  • 添加了高性能JSON API,用于reader/writer,对象模型和序列化方案。这些API从头开始构建,Span并在幕后使用UTF8而不是UTF16(例如string)。这些API最小化分配,从而提高了性能,减少了垃圾收集器的工作。请参阅尝试新的System.Text.Json API。
  • 默认情况下,垃圾收集器使用较少的内存,通常少得多。对于许多应用程序托管在同一服务器上的情况,此改进非常有用。垃圾收集器也进行了更新,以更好地利用64核以上的机器上的大量核。请参阅在具有64个以上CPU的计算机上为GC更好地配置CPU配置。
  • .NET Core已针对Docker进行了强化,以使.NET应用程序在容器中可预测且有效地工作。已将容器配置为有限的内存或CPU时,垃圾收集器和线程池已更新为更好地工作。.NET Core Docker窗映像较小,尤其是SDK映像。请参阅:在小型容器场景中使用服务器GC运行第0部分,在小型容器场景中使用服务器GC运行第1部分-GC堆的硬限制以及同时使用.NET和Docker-DockerCon 2019更新。
  • 现在支持Raspberry Pi和ARM芯片以支持IoT开发,包括使用远程Visual Studio调试器。您可以使用新的GPIO API部署可监听传感器的应用程序,并在显示器上打印消息或图像。ASP.NET可用于将数据公开为API或允许配置IoT设备的站点。支持平台以下操作系统支持.NET Core 3.1:
  • Alpine: 3.9+
  • Debian: 9+
  • openSUSE: 42.3+
  • Fedora: 26+
  • Ubuntu: 16.04+
  • RHEL: 6+
  • SLES: 12+
  • macOS: 10.13+
  • Windows Client: 7, 8.1, 10 (1607+)
  • Windows Server: 2012 R2 SP1+
    注意:Windows窗体和WPF应用程序仅在Windows上起作用并受支持。

芯片支持如下:

  • Windows,macOS和Linux上的x64
  • Windows上的x86
  • Windows和Linux上的ARM32
  • Linux上的ARM64(内核4.14+)

注意:请确保.NET Core 3.1 ARM64部署使用Linux内核4.14版本或更高版本。例如,Ubuntu 18.04满足此要求,但16.04不满足。

Windows窗体控件删除
以下Windows窗体控件已从.NET Core 3.1中删除:

  • 数据网格
  • 工具栏
  • 上下文菜单
  • 菜单
  • 主菜单
  • 菜单项

早在2005年,这些控件就被.NET Framework 2.0中更强大的控件所取代。默认情况下,多年来,Visual Studio Designer工具箱中都没有提供这些控件。结果,我们决定删除这些控件,而只关注新控件。

建议使用以下替代产品:

旧控件(API)建议更换其他关联的API已删除DataGridDataGridViewDataGridCell,DataGridRow,DataGridTableCollection,DataGridColumnCollection,DataGridTableStyle,DataGridColumnStyle,DataGridLineStyle,DataGridParentRowsLabel,DataGridParentRowsLabelStyle,DataGridBoolColumn,DataGridTextBox,GridColumnStylesCollection,GridTableStylesCollection,HitTestTypeToolBarToolStripToolBarAppearanceToolBarButtonToolStripButtonToolBarButtonClickEventArgs,ToolBarButtonClickEventHandler,ToolBarButtonStyle,ToolBarTextAlignContextMenuContextMenuStripMenuToolStripDropDown,ToolstripDropDownMenuMenuItemCollectionMainMenuMenuStripMenuItemToolstripMenuItem

是的,这是一个不幸的重大变化。如果您使用的是我们在应用程序中删除的控件,则会看到构建中断。另外,如果在最新版本的.NET Core Windows窗体设计器中打开.NET Core 3.0应用程序,则在使用这些控件时会看到错误。

我们建议您将应用程序更新为.NET Core 3.1,然后移至其他控件。更换控件是一个简单的过程,本质上是“查找并替换”。

首先,我们应该在发布.NET Core 3.0之前进行这些更改,对此我们表示赞同。我们尝试避免过时的更改,甚至避免突破性更改,这使我们很痛苦。

随着我们进一步进入Windows Forms设计器项目,我们意识到这些控件与创建现代应用程序不符,并且永远不应该成为Windows Forms的.NET Core端口的一部分。我们还看到,他们需要我们更多的时间来支持而不是合理的。

我们的目标是继续改进Windows窗体,以实现更高的DPI,可访问性和可靠性,并且需要后期更改才能使我们专注于交付。

C ++ / CLI

我们在Visual Studio 2019 16.4中增加了对创建可与.NET Core 3.0+一起使用的C ++ / CLI(又称为“托管C ++”)组件的支持。您需要安装“带C ++的桌面开发”工作负载和“ C ++ / CLI支持”组件,才能使用C ++ / CLI。

该组件添加了几个可以使用的模板:

  • CLR Class Library (.NET Core)
  • CLR Empty Project (.NET Core)
    如果找不到它们,只需在“新建项目”对话框中搜索它们。

C++ / CLI仅在Windows上启用。您不能将目标为.NET Framework的C ++ / CLI组件与.NET Core一起使用,反之亦然。

结束

我们建议您尽快迁移到.NET Core 3.1。这是一个很棒的版本(很大程度上是由于3.0),它对.NET Core的许多方面进行了改进。这也是一个长期支持(LTS)版本,将支持三年。

生命周期更新:

  • .NET Core 3.0将于今天(到2020年3月3日)维护三个月。
  • .NET Core 2.2的整个维护周期都将在12月23日结束。
  • .NET Core 2.1的支持将一直持续到2021年8月(这也是LTS版本)。

来源:赚钱

原文地址:https://www.cnblogs.com/1994jinnan/p/12324623.html

时间: 2024-10-11 01:12:29

「翻译」.NET Core3.1发布的相关文章

「翻译」一篇redis文章引发的翻译——JVM能支持多少线程?

昨天看了一篇关于redis 的文章https://www.cnblogs.com/fanwencong/p/5782860.html 作者说他模拟了100万线程的并发,我对这个有一些怀疑,看了评论也有很多质疑的声音.当然我这篇不是要批评作者对线程的模拟,事实上作者写的对redis的使用是很不错的,我们本篇主要针对个人电脑上的JVM最多能支持多少个线程.以下是StackOverflow上的一个提问,我简单的翻译了一下. StackOverflow原回答请点我 Eddie 的回答 This depe

Linux 小知识翻译 - 「补丁」(patch)

这次,聊聊补丁. 当有bug或者安全漏洞的时候,就会发布补丁.打上补丁之后,就能解决相应的bug或者安全漏洞. 那么,「补丁」到底是什么呢? 「补丁」只有少量的代码,一般都是对程序的一部分进行更新或者追加,包括bug修正,安全漏洞修正,功能追加或者变更等等.当然,只有「补丁」是无法运行的. 即,只有将「补丁」附加到原来的程序中,更新原来的程序后,才能运行. 「补丁(patch)」本来是指「打补丁用的小布头」.「patch」正是为了补足现有的程序,堵住程序漏洞的「布头」. 打「补丁」的时候需要用到

Linux 小知识翻译 - 「版本号」的命名方式

包括OS,所有的软件都有版本号信息.一般来说,版本号的增大表示软件的功能增强了或者修正了一些Bug,也就是表示软件更新了. 版本号的命名方式没有统一的标准.每种软件都不一样. 大部分情况下,版本号以「X.Y」或者「X.Y.Z」的方式命名,软件有大幅的功能增强时,增加「X」的数值,只有微小的改变时,增加「Y」或者「Z」的数值. 因此,「X」被称为「主版本号」,「Y」或者「Z」被称为「次版本号」. 但是,版本号有时还有其他的含义.比如Linux内核的版本号,现在是以「X.Y.Z」的方式命名的,200

Linux 小知识翻译 - 「Linux」和「发行版」之间的关系

「Linux」本来指的仅仅是内核.5年之前大多都是这么认为的,但是最近不这么说了. 最近一般都说「Linux」是个 OS,这里的OS,不仅仅是内核,而是指电脑的整体环境(除了内核,还包括一些外围的软件). 内核本来是作为硬件和各种应用软件之间的桥梁而存在的,只有内核的PC是无法使用的. 因此,会将各式各样的软件和内核组合在一起,作为一个可以运行的OS来打包,打包后的OS就被称为「Linux发行版」. 最近,把「Linux发行版」称为「Linux」的情况也比较多了. 但是,「Linux内核」只有一

Linux 小知识翻译 - 「syslog」

这次聊聊「syslog」. 上次聊了「日志」(lgo).这次说起syslog,一看到log(日志)就明白是怎么回事了.syslog是获取系统日志的工具. 很多UINIX系的OS都采用了这个程序,它承担了「获取系统全部的日志」这个维持系统正常运行的重要任务. syslog的本体是「syslogd」这个daemon(一般翻译成守护进程),常驻内存中获取日志. syslog的特点是可以通过配置文件「/etc/syslog.conf」,对「哪种应用程序?哪种重要度的信息?记录在哪个文件中?」等进行细致的

Linux 小知识翻译 - 「日志」(log)

这次聊聊「日志」. 「日志」主要指系统或者软件留下的「记录」.出自表示「航海日志」的「logbook」. 经常听说「出现问题的时候,或者程序没有安装自己预期的来运行的时候,请看看日志!」. 确实,记录了系统和软件详细运行情况的「日志」是信息的宝库,通过日志来解决问题的事例也非常多. 但事实上,「无论如何也不会看日志」的用户也有很多.理由很简单,日志的信息量非常大,全部用眼睛来看的话是非常吃力的. 而且,英语写的日志也会让英文不好的人敬而远之. 虽说「要养成用眼睛来看日志的习惯」,但实行起来却非常

Linux 小知识翻译 - 「Linux」怎么读?

主要讨论日语中的读法,所以没有完全按照原文来翻译. 「linux」的读法有很多(这里指在日语中),代表性的读法有以下几种: A). 李纳苦思 B). 李奴苦思 C). 纳依纳苦思 A和B相同的是将 linux开头的「li」发音成「李」.这也是linux之父Linus Torvalds的名字的日语假名(「リーナス?トーバルズ」)的由来. linux中「nu」的发音是怎么样的呢?Linux Online的网页上有说明,而且视频中还有 Linus Torvalds 的发音. http://www.li

Linux 小知识翻译 - 「Linux」和病毒

据说,「Linux」系统上的病毒要远远少于Windows系统上病毒.从2种系统的普及度来看,这是很显然的, 「Linux」的使用人群很少,所以「Linux」上的病毒的扩散时,受害的范围也不大. 但是,认为「Linux上不存在病毒」,「Linux不需要病毒防范策略」等等都是不对的. Linux感染病毒的情况也是有的,不仅如此,在Linux服务器上情况更为显著,比如一个windows平台的病毒混入了Linux服务器中, 其他连接此Linux服务器的Windows系统也有可能会感染这个病毒的. 使用L

Linux 小知识翻译 - 「i386」是什么?

i386是指 *CPU* 的种类,也可以指 *CPU* 的架构(architecture). 现在的 CPU 一般都用 「Core 2 Duo」或者「Athlon」,「Xeon」,「Opteron」之类的比较酷的名称来称呼. Linux诞生的时候,CPU作为一个重要的组件,一般用型号来称呼它. i386的 i 代表 Intel. Intel公司最先生产的,从4004开始的CPU系列中,386(80386)是第一个32位的CPU. Linux刚开始就是作为386架构上兼容POSIX的内核来开发的.