如何分析旧版.NET程序集，评估代码向.NET 8.0/9.0的可移植性？

先搞定 .NET Portability Analyzer 的新版本支持问题 #

• 先更到最新版：Portability Analyzer 现在已经支持.NET 8了，如果你用的是Visual Studio里的旧扩展，直接去扩展商店更到最新版；命令行工具的话，用dotnet tool update -g microsoft.dotnet.portability-analyzer.tool更新。
• 命令行显式指定目标：GUI版本可能有时候识别不到新框架，换命令行试试，直接加参数指定目标框架，比如dotnet pa -f net8.0 -f net9.0 你的项目路径，命令行的灵活性更高，能绕开GUI的限制。
• 手动加.NET9规则（进阶）：如果工具还没内置.NET9的规则，你可以找到工具安装目录下的PortabilityRules.json，手动添加net9.0的TFM条目，不过这需要你自己整理.NET9的API兼容数据，适合有经验的开发者折腾。

换用更适配新版本的评估工具 #

• .NET Upgrade Assistant 是首选：这个工具比Portability Analyzer更全面，不光能扫可移植性，还能帮你自动改项目文件、升级包、替换过时API。直接在命令行跑dotnet upgrade-assistant analyze 你的项目，会生成详细的迁移报告，明确告诉你哪块有问题、怎么改，完全支持.NET8/9。
• 直接编译试错：最粗暴但有效的方法，把项目的TargetFramework改成net8.0，然后编译，编译器会把所有API兼容错误直接抛出来——比如某个方法被移除了、某个类型移到别的命名空间了，照着错误提示一个个修就行。还可以用条件编译指令#if NET8_0来兼容新旧框架的差异代码。
• 检查NuGet包兼容性：用dotnet list package --outdated看看所有依赖包有没有支持.NET8/9的版本，很多旧包可能已经停更了，得找替代或者升级。另外dotnet restore的时候注意看警告，有些包虽然能装但兼容性不好，提前处理掉。

平稳迁移的保障措施 #

• 靠单元测试兜底：迁移前确保核心逻辑都有单元测试覆盖，迁移完直接跑测试，能快速发现功能有没有崩。如果之前没写测试，先补核心模块的，别等全迁完再找问题。
• 分步迁移别贪快：如果应用体量很大，别一次性全迁。可以先把类库升级到.NET Standard 2.1（兼容.NET8/9和旧.NET Framework），然后慢慢把主项目切过去，或者先迁几个小模块，验证没问题再扩。
• 用兼容性开关减少麻烦：.NET提供了很多兼容性开关，比如针对WinForms高DPI的、针对.NET Framework行为兼容的，在项目文件里加这些开关，能减少迁移时的UI或者逻辑行为差异，比如<EnableWindowsFormsHighDpiAutoResizing>true</EnableWindowsFormsHighDpiAutoResizing>。

内容的提问来源于stack exchange，提问作者Needyboy