创建移植计划

2024-01-04

建议使用 Visual Studio .NET 升级助手将 .NET Framework 代码更新到最新的 .NET 版本。有关详细信息，请参阅博客使用 Visual Studio 升级 .NET 项目。

重要

API 端口已弃用，支持使用 .NET 升级助手工具进行二进制分析。 API 端口的后端服务已关闭，因此要使用该工具，必须以脱机方式使用。有关详细信息，请参阅 .NET API 端口自述文件。

在直接了解代码之前，请花时间完成建议的迁移前步骤。本文让你深入了解可能遇到的问题类型，并帮助确定最有意义的方法。

移植代码

继续下一步之前，请确保遵循移植代码的先决条件。准备好决定最适合你的方法并开始移植代码。

主要处理编译器

此方法可能较适合小项目或不会用很多 .NET Framework API 的项目。此方法很简单：

可选择在项目上运行 ApiPort。若运行 ApiPort，则从报告获取有关需要解决的问题的信息。
将所有代码复制到新的 .NET 项目。
查看可移植性报表（如果已生成）时，解决编译器错误，直至项目完全得到编译。

尽管它是非结构化的，但这种以代码为中心的方法通常可以快速解决问题。只包含数据模型的项目可能是此方法的理想选择。

可移植性问题得到解决前停留在 .NET Framework 上

如果更希望拥有在整个过程期间编译的代码，此方法可能是最佳选择。该方法如下所示：

在项目上运行 ApiPort。
通过使用可移植的不同 API 解决问题。
记录阻止你使用直接替代方案的所有区域。
对所有要移植的项目重复前面的步骤，直到确信每个项目都做好被复制到新的 .NET 项目中的准备。
将代码复制到新的 .NET 项目中。
解决所有已记录的不存在直接替代方案的问题。

这种谨慎的方法比单纯解决编译器错误更有条理，但相对而言，它仍以代码为中心，且优点是始终拥有编译的代码。解决不能通过只使用另一个 API 解决的某些问题的方法大不相同。你可能会发现对于某些项目，需要制定更全面的计划，这将在下一种方法中介绍。

制定全面的攻击计划

此方法可能最适合大型或更复杂的项目，在这种情况下，为支持 .NET，可能必需重构代码或将某些代码区域完全重写。该方法如下所示：

在项目上运行 ApiPort。
了解每个非可移植类型使用的位置以及位置对整体可移植性的影响。
- 了解这些类型的特性。它们是否数量少，但使用频繁？它们是否数量大，但使用不频繁？它们是串联使用，还是在整个代码中传播？
- 是否可以轻松隔离不可移植的代码，以便可以更有效地处理它？
- 是否需要重构代码？
- 对于这些不可移植的类型，是否存在可完成相同任务的备用 API？例如，如果使用的是 WebClient 类，则改用 HttpClient 类。
- 是否存在其他可用于完成任务的可移植 API，即使它不是直接替代 API？例如，如果使用 XmlSchema 来分析 XML，但是无需 XML 架构发现，则可使用 System.Xml.Linq API 并自行实现分析，而不是依赖于某个 API。
如果具有难以移植的程序集，是否值得将其暂时留在 .NET Framework 上？以下是一些需要考虑的事项：
- 库中可能具有某些与 .NET 不兼容的功能，因为它过于依赖 .NET Framework 或 Windows 特定的功能。是否值得暂时搁置该功能，并直到资源可用于移植这些功能，才发布具有较少功能的库的临时 .NET 版本？
- 重构是否有用？
编写自己对不可用 .NET Framework API 的实现是否合理？

可以考虑复制、修改，并使用 .NET Framework 参考源中的代码。参考源代码已在 MIT 许可证下获得许可，因此可以自由选择将此源作为自己代码的基础。只需确保在代码中正确设置 Microsoft。
根据不同项目的需要，重复此过程。

分析阶段可能需要一些时间，具体取决于代码库的大小。在此阶段花费时间（尤其是在具有复杂的代码库时），全面了解所需的更改范围并制定计划，最终通常可节省时间。

计划可能包括对代码库做重大更改，同时仍面向 .NET Framework 4.7.2。这是前一种方法更有条理的版本。着手执行计划的方式具体取决于代码库。

混合方法

在每个项目的基础上，可能会将上述方法进行混合。执行哪些操作对你和代码库最有意义。

移植测试

要确保移植代码后一切正常的最佳方式是在将代码移植到 .NET 时进行测试。为此，需要使用将针对 .NET 生成和运行测试的测试框架。当前，有三个选择：

通过