介绍
9 月, 微软发布了新版. NET Core, 用于构建 Windows 桌面应用程序, 包括 WPF 和 Windows Forms. 从那时起开发人员可以将传统的 nfx 桌面应用程序 (和控件库) 迁移到. NET Core. 一般使用 WPF 和 Windows Forms 开发的业务范围包括:
UI 密集数据形式 (FOD) 应用程序
响应式低延迟 UI
需要脱机 / 断开连接运行的应用程序
依赖于自定义设备驱动程序的应用程序
这只是. NET Core 上 Windows 应用程序开发的开始. 继续阅读以了解有关. NET Core 对构建 Windows 应用程序更多好处的信息.
为什么在. NET Core 上使用 Windows desktop?
.NET Core(以及将来在. NET Core 之上构建的. NET 5)将是. NET 的未来. 在未来几年内微软将继续支持. NET Framework, 但是不会增加任何新功能, 这些新功能只会添加到. NET Core(最终是. NET 5)中. 为了改进 Windows 桌面应用领域, 并使. NET 桌面开发人员可以从中受益, 微软将 Windows Forms 和 WPF 引入了. NET Core, 但因为与 Windows API 紧密相关, 所以仍将仅支持 Windows 平台. 但是. NET Core 除了可以跨平台使用外, 还具有许多其他功能, 可以增强桌面应用程序.
首先, 所有运行时改进和语言功能将仅添加到. NET Core 中, 以后也将添加到. NET 5 中. 一个很好的例子是 C# 8, 它已在. NET Core 3.0 中可用. 而且 Windows Forms 和 WPF 的. NET Core 版本将成为. NET 5 平台的一部分.
此外,.NET Core 通过. NET Framework 中不可用的新选项为应用程序带来了部署灵活性, 例如:
并行部署. 可以在同一台计算机上拥有多个. NET Core 版本, 并且可以选择每个应用程序应针对的版本.
独立部署. 可以与应用程序一起部署. NET Core 平台, 并完全独立于最终用户环境.
较小的应用程序大小. 在. NET Core 3 中, 微软引入了一个称为链接器 (有时也称为微调器) 的新功能, 该功能将分析代码并将所需的程序集包括在自包含的部署中, 不需要的都将被修剪掉.
单个. exe 文件. 可以将应用程序和. NET Core 平台打包在一个. exe 文件中.
改进了运行时性能. 与. NET Framework 相比,.NET Core 具有许多性能优化. 具体来说, 在很大程度上依赖于 I/O 操作, 网络和数据库操作的桌面应用程序可能会看到这些方面的性能提高. 在 UI 渲染性能或应用程序启动性能有一定的提示, 但不是很高.
使用 ReadyToRun 优化. NET Core 应用
通过将应用程序程序集编译为 ReadyToRun(R2R)格式, 可以缩短. NET Core 应用程序的启动时间. R2R 是一种提前 (AOT) 编译的形式. 它是. NET Core 3.0 中的发布时选择功能.
R2R 二进制文件通过减少应用程序加载时 JIT 需要完成的工作量来提高启动性能. R2R 二进制文件较大, 因为它们既包含中间语言 (IL) 代码(某些情况下仍然需要此代码), 也包含相同代码的本机版本, 以改善启动.
要启用 ReadyToRun 编译:
将 PublishReadyToRun 属性设置为 true.
使用显式发布 RuntimeIdentifier.
注意: 编译应用程序程序集时, 生成的本机代码特定于平台和体系结构(这就是发布时必须指定有效的 RuntimeIdentifier 的原因).
下面是一个例子:
- <Project Sdk="Microsoft.NET.Sdk">
- <PropertyGroup>
- <OutputType>Exe</OutputType>
- <TargetFramework>netcoreapp3.0</TargetFramework>
- <PublishReadyToRun>true</PublishReadyToRun>
- </PropertyGroup>
- </Project>
并使用以下命令发布:
dotnet publish -r win-x64 -c Release
注意:
RuntimeIdentifier 可以将其设置为其他操作系统或芯片. 也可以在项目文件中设置.
如果在发布过程中遇到错误, 请添加
<PublishReadyToRunShowWarnings>true</PublishReadyToRunShowWarnings>
查看详情日志.
Assembly linking
.NET core 3.0 SDK 附带了一个工具, 该工具可以通过分析 IL 和修剪未使用的程序集来减小应用程序的大小. 这是. NET Core 3.0 中的另一个发布时选择加入功能.
借助. NET Core, 始终可以发布包含运行代码所需的一切的自包含应用程序, 而无需在部署目标上安装. NET. 在某些情况下, 该应用仅需要框架的一小部分即可运行, 并且可能仅包含所使用的库就可以变得更小.
使用 IL 链接器 https://github.com/mono/linker 扫描应用程序的 IL, 以检测实际需要哪些代码, 然后修剪未使用的框架库. 这可以大大减小某些应用程序的大小. 通常, 类似小型工具的控制台应用程序受益最大, 因为它们倾向于使用框架的较小子集, 并且通常更易于调整.
要使用链接器:
将 PublishTrimmed 属性设置为 true.
使用显式发布 RuntimeIdentifier.
下面是一个例子:
- <Project Sdk="Microsoft.NET.Sdk">
- <PropertyGroup>
- <OutputType>Exe</OutputType>
- <TargetFramework>netcoreapp3.0</TargetFramework>
- <PublishTrimmed>true</PublishTrimmed>
- </PropertyGroup>
- </Project>
并使用以下命令发布:
dotnet publish -r win-x64 -c Release
注意: RuntimeIdentifier 可以将其设置为其他操作系统或芯片. 也可以在项目文件中设置.
经测试对于 helloworld 应用程序, 大小从68MB 减小到28MB.
修剪后使用反射或相关动态功能的应用程序或框架 (包括 ASP.NET Core 和 WPF) 通常会中断, 因为链接器不了解这种动态行为, 并且通常无法确定反射所需的框架类型在运行时. 要修剪此类应用程序, 您需要告知链接器有关代码中以及依赖的任何包或框架中反射所需要的任何类型. 修剪后一定要测试应用程序. 针对这个问题微软在. NET 5 上正在努力改善.
有关 IL Linker 的更多信息, 请参阅文档 https://aka.ms/dotnet-illink , 或访问 mono / linker 存储 https://github.com/mono/linker 库.
注意: 在. NET Core 的早期版本中, ILLink.Tasks 作为外部 NuGet 软件包提供, 并提供了许多相同的功能. 请更新到. NET Core 3.0 SDK, 然后尝试新的体验!
Assembly linking 和 ReadyToRun compiler 可用于同一应用程序. 通常, Assembly linking 使应用程序更小, ready-to-run compiler 使应用程序更大一些, 但在性能上有明显优势. 可以在各种配置中进行测试以了解每个选项的影响.
发布单文件可执行文件
可以使用发布单个文件的可执行文件 dotnet publish. 这种形式的单个 EXE 实际上是一个自解压缩的可执行文件. 它包含所有依赖项 (包括本地依赖项) 作为资源. 在第一次启动时, 它将所有依赖项复制到一个临时目录, 并在该目录中加载它们. 它只需要解压缩依赖项一次. 当再次启动时将会很快启动, 并且没有任何损失.
可以通过将 PublishSingleFile 属性添加到项目文件或在命令行上添加新的参数来启用此发布选项.
要生成一个独立的单个 EXE 应用程序, 在这种情况下, 对于 64 位 Windows:
dotnet publish -r win10-x64 /p:PublishSingleFile=true
注意:
RuntimeIdentifier 可以将其设置为其他操作系统或芯片. 也可以在项目文件中设置.
关于临时目录, 请参考 Extracting Bundled Files to Disk
有关更多信息, 请参见单文件捆绑器 https://github.com/dotnet/core-setup/pull/5286 .
Assembly trimmer, ahead-of-time compilation(通过 crossgen)和单个文件捆绑都是. NET Core 3.0 中的所有新功能, 可以一起使用, 也可以单独使用.
综合使用
通过设置属性 < PublishSingleFile>,<RuntimeIdentifier>,<PublishTrimmed>, <PublishReadyToRun>,<PublishReadyToRunShowWarnings > 在发布配置文件中, 能够将修剪, ahead-of-time compilation 后的自包含应用程序部署为单个. exe 文件, 如下面的示例所示.
- <PropertyGroup>
- <OutputType>Exe</OutputType>
- <TargetFramework>netcoreapp3.0</TargetFramework>
- <PublishSingleFile>true</PublishSingleFile>
- <RuntimeIdentifier>win-x64</RuntimeIdentifier>
- <PublishReadyToRun>true</PublishReadyToRun>
- <PublishReadyToRunShowWarnings>true</PublishReadyToRunShowWarnings>
- <PublishTrimmed>true</PublishTrimmed>
- </PropertyGroup>
然后使用 Visual Studio 发布工具或者命令 dotnet publish -c release 发布.
MSIX
如果你正在寻找一种将应用程序分发给最终用户的方法, 那么将其打包为 MSIX https://docs.microsoft.com/en-us/windows/msix/ 可能比创建单个. exe 文件更好. PublishSingleFile 提供了一个包含所有应用程序依赖项的自解压 ZIP 文件, 而 MSIX 提供了干净可靠的 Windows 集成应用程序安装和卸载.《MSDN 杂志》上写了一篇文章 https://msdn.microsoft.com/en-us/magazine/mt833462 , 不仅展示了如何打包应用程序, 而且还展示了如何为 MSIX 包设置持续集成 (CI), 持续部署(CD) 和自动更新.
.NET Framework desktop 和. NET Core desktop 之间的区别
WPF 应用程序在. NET Core 上完全受支持. 对于 Windows Forms, 运行时部分已完全移植到. NET Core, 并且微软团队正在继续开发 Windows 窗体设计器. 微软计划在 2020 年第四季度之前将其准备就绪, 现在可以在 Visual Studio 预览下载页面 https://visualstudio.microsoft.com/vs/preview/ 16.4 Preview 3 或更高版本中签出设计器的 Preview 版本. 别忘了在工具 ->选项 ->预览功能 ->使用. NET Core 应用程序的 Windows 窗体设计器预览, 然后重新启动 Visual Studio.
重大变化
.NET Framework 和. NET Core 之间有一些重大更改, 但与 Windows 窗体和 WPF 区域相关的大多数代码都按原样移植到了 Core. 如果使用的组件包括 WCF 客户端, 代码访问安全性, 应用程序域, 互操作性和远程处理, 则要切换到. NET Core, 则需要重构代码.
请记住另一件事,.NET Core 上的默认输出路径与. NET Framework 上的默认输出路径不同, 因此, 如果在代码中对正在运行的应用程序的文件 / 文件夹结构进行了一些假设, 则它可能会在运行时失败.
此外, 配置. NET 功能的方式也有所变化..NET Core 而非 machine.config 文件使用的 < something>.runtimeconfig.JSON 是应用程序随附的文件, 该文件具有相同的通用目的和相似的信息. 一些配置, 如 system.diagnostics,system.NET 或 system.servicemodel 不被支持, 那么应用程序配置文件将失败是否含有这些内容的加载. 此更改影响 System.Diagnostics 以前使用 xml 配置通常配置的跟踪和 WCF 客户端方案. 在. NET Core 中, 需要改为在代码中进行配置. 要更改行为而无需重新编译, 请考虑使用从 Microsoft.Extensions.Configuration 源或从中加载的值来设置跟踪和 WCF 类型 appSettings.
可以在. NET Core 无法使用的. NET Framework 技术找到有关. NET Core 和. NET Framework 之间差异的更多信息.
从. NET Framework 移植到. NET Core
首先, 运行可移植性分析器并在需要时更新代码以与. NET Core 100%兼容. 这是有关使用可移植性分析器的说明. 建议在对应用程序进行任何更改之前使用源代码控制或备份代码, 以防重构无法按照希望的方式进行.
当应用程序与. NET Core 完全兼容时, 就可以准备移植它了. 首先, 可以尝试使用工具 https://github.com/dotnet/try-convert 以帮助将. NET Framework 项目自动转换为. NET Core.
此工具只是通往. NET Core 的起点. 它也不是受支持的 Microsoft 产品. 尽管它可以帮助解决迁移的某些机械问题, 但它不能处理所有方案或项目类型. 如果遇到该工具无法转换的项目, 则必须手动进行移植.
关于. Net Core3.1 的支持
来源: https://www.cnblogs.com/muran/p/11808508.html