随着 .NET 6.0 的发布 NewLife 组件也进行了升级，并在 2022 年 1 月份全面停止了对 .NET Framework 的支持框架依赖升级至 .NET Standard 2.1 。
2022 年新年到来之际，笔者也打算将路遥工具箱全面迁移至 .NET 6.0 同时发布 3.0 版本。这意味着路遥工具箱将获得更先进的技术和加快的运行速度。
目录
从 .NET Framework 4.6.2 到 .NET 6 的迁移过程
更改目标框架
因为从立项之初就采用了新版本的 csproj 格式，所以迁移过程并不复杂。在项目属性页面中将目标框架从 .NET Framework 4.6.2 更改为 .NET 6.0 之后，大部分工作其实就已经完成了。需要注意的是“目标操作系统版本”和“受支持的 OS 版本”需要设置为 7.0 才可以兼容 Windows 7 操作系统。
移除过时依赖
在 .NET Framework 4.6.2 环境下，路遥工具箱通过引用类库的方式添加了对 System.ComponentModel.DataAnnotations 和 WindowsFormsIntegration 程序集的依赖。在 .NET 6.0 中，这两个程序集已经被默认包含，所以以下代码可以从项目文件中删除：
<ItemGroup> <Reference Include="System.ComponentModel.DataAnnotations" /> <Reference Include="WindowsFormsIntegration" /> </ItemGroup>添加对 GB2312 编码的支持
这是一个中文编程环境下绕不过的问题，很纳闷为什么微软没有将其内置。
.NET 6.0 中默认不支持 GB2312、GBK编码。要启用支持需要通过 NuGet 引入 System.Text.Encoding.CodePages ，地址在这里： 。然后在 App 的 OnStartup 方法中调用方法（路遥工具箱是使用 WPF 开发的，并且使用了 Prism 框架）：
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);UTF8 和 UTF8-without-BOM
UTF-8 不需要 BOM，尽管 Unicode 标准允许在 UTF-8 中使用 BOM。所以不含 BOM 的 UTF-8 才是标准形式，在 UTF-8 文件中放置 BOM 主要是微软的习惯（顺便提一下：把带有 BOM 的小端序 UTF-16 称作「Unicode」而又不详细说明，这也是微软的习惯）。BOM（byte order mark）是为 UTF-16 和 UTF-32 准备的，用于标记字节序（byte order）。微软在 UTF-8 中使用 BOM 是因为这样可以把 UTF-8 和 ASCII 等编码明确区分开，但这样的文件在 Windows 之外的操作系统里会带来问题。
作者：梁海链接：来源：知乎
在 .NET 6.0 中，如果使用默认的 UTF-8 编码去写文件则该文件默认是带 BOM 的。因为路遥工具箱的升级接口部署在 Linux 服务器上，所以使用 .NET 6.0 上传的 XML 文件在浏览时会报错。
写文件的代码类似这样：
var str = Serialize(updatePackage); File.WriteAllText(path, str, Encoding.UTF8);报错信息：
XML declaration allowed only at the start of the document解决办法就是采用无 BOM 的 UTF-8 编码，以上代码修改一下即可：
var str = Serialize(updatePackage); File.WriteAllText(xml, fn, new UTF8Encoding(false));同时兼容 x86 和 x64 的打包发布
在 .NET 6.0 中，程序的入口 exe 变成了本地化代码。这也就代表着类似 .NET Framework 下那种一个 exe 可以同时适应 x86、x64 神器操作没有了。
为了能更高效率地发挥路遥工具箱的性能，同时也兼顾目前仍在使用 x86 系统的用户，路遥工具箱采用了 x64 为主且附带 x86 支持的发布形式。
通过 Visual Studio 内置的发布功能将路遥工具箱使用 windows-x86 发布一次，即可得到一个 32 位的入口程序 exe 文件。将该文件改名为 Luyao.Toolkit-x86.exe 后复制到项目中，并设置为“始终复制”。这样每次生成新的 release 版本都是 64 位的并且携带了 32 位的启动器。