.NET Framework升级.NET8之二: 前期准备工作
前言
从.NET Framework迁移到.NET8可以为应用的带来性能、托管费用和可维护性等方面的巨大优势。但在开始破坏性操作之前，了解应用的升级路径至关重要。那么，如何确保迁移工作按部就班地进行呢？
准备阶段
将应用迁移到较新的.NET版本，是全面审视当前应用架构、解决技术债务的绝佳契机。若应用架构混乱或背负过多技术债务，迁移工作将变得异常艰难。因此，现在正是对应用进行全面审查、确保在考虑“迁移就绪”之前解决这些问题的时候。
手动依赖分析
以典型的多层应用为例，在其生命周期中，各层之间的界限往往变得模糊，可能会出现诸如System.Web引用出现在应用或数据层等不恰当的地方，这是常见的代码异味，也是清理应用的良好起点。
如果应用有第三方依赖（例如与金融系统、报告系统等的集成），现在是调查这些集成点以确定服务是否提供兼容库以及这些库有何差异（如果有的话）的时候。同时为这些依赖创建产品待办事项（PBIs）。
基础设施
如果应用在本地托管，检查基础设施是否具备必要的运行时环境也非常重要。
破坏性变更
在解决任何技术债务或架构问题之后，便可以开始评估迁移本身所需的工作量。
::: greybox 提示： 对于多层应用（或采用洋葱架构的应用），应自底向上（或由内而外）进行迁移。这样可以逐步推进迁移工作，并在上游解决任何破坏性变更。若自顶向下（或由外而内）迁移，可能会多次重写下游代码。 :::
升级csproj文件
首先，将项目中的csproj文件更新为新的SDK样式格式。这不仅大大简化了文件内容，还使同时针对多个版本的.NET框架单名（TFMs）变得更加容易。
提示： 可以使用try-convert dotnet工具将项目转换为新的sdk样式csproj格式。
使用以下命令安装工具：
dotnet tool install -g try-convert
…以及使用以下命令转换其他项目：
try-convert --keep-current-tfms
针对多个目标框架单名（TFM）
现在，您已经拥有了崭新的SDK样式csproj文件，是时候看看哪些地方会出现问题了！
同时针对当前的.NET Framework版本和未来的.NET版本，将为您提供以下信息：
- 尝试针对.NET时遇到的任何构建错误
- 尝试针对.NET Framework时遇到的任何构建错误
为什么这一点很重要？
假设您没有这样做，而是直接将目标对准较新的.NET版本。结果，您遇到了100个由于破坏性变更导致的构建错误——数量太多，无法在一个冲刺（或两个、三个）内解决。
您开始修复这些构建错误。从100个错误减少到50个——进展显著！
然后，您被告知需要立即修复一个紧急的错误/功能/其他问题。但当您将目标对准.NET时，仍然存在50个构建错误。
“没问题，”您说，“我会切换回.NET Framework，进行修复，然后推出新部署。”
您切换到.NET Framework，构建项目，却出现了25个构建错误？！
在修复构建错误的过程中，您编写了与.NET Framework不兼容的代码。现在，您不仅有紧急的错误/功能/其他问题需要解决，还有25个新的构建错误需要解决？。
从第一天开始针对多个TFMs，可以确保在修复.NET的破坏性变更时，不会在.NET Framework中引入破坏性变更。
这使您能够逐步处理迁移PBIs，同时仍然可以在当前的.NET版本上部署应用——双赢！
在所有项目文件中，将TargetFramework标签更改为TargetFrameworks。您希望尽早进行此操作，以便之后能够更流畅地进行，无需卸载和重新加载项目或关闭并重新打开Visual Studio。
<TargetFrameworks>net472;net8.0</TargetFrameworks>
创建迁移待办事项列表
此时，确保项目能够同时针对.NET Framework和新的目标.NET。有些项目可能无法立即支持这两个平台，您可以按照以下步骤修复问题，并更好地了解可能需要完成的工作量。
- 将目标框架添加到项目中
- 编译以查看哪些地方出现问题
- 修复容易修复的问题
- 记得在每次修复后提交更改，以帮助审查者？。
- 对于不容易修复的问题，创建一个包含问题详细信息的PBI。
- 这样可以允许团队中的其他开发人员独立处理该PBI。
- 如果此时项目能够成功编译，您可以将新的TFM保留在项目中，并继续处理下一个项目。
- 如果不能，您可以移除新的TFM并继续处理下一个项目。
- 在与该项目相关的PBIs完成后，重复这些步骤。
通过这一过程，您将对通往最新.NET的道路有一个更清晰的视图（和待办事项列表！）：
- 技术债务的PBIs
- 架构问题的PBIs
- 破坏性变更的PBIs
