如何查找解决方案中.NET Core/.NET 6不兼容成员的实际使用位置？

针对你提到的现有工具无法定位不兼容成员具体代码位置、Upgrade Assistant覆盖场景有限的问题，以下是几个可落地的方案，兼顾精准性和CI/CD自动化需求：

一、基于Roslyn+Portability Analyzer核心库的一站式分析方案 #

你构思的Roslyn扫描思路是可行的，可通过复用微软官方的Portability Analyzer核心库减少重复工作量：

• 直接引用Microsoft.CodeAnalysis.Portability NuGet包，该包是Portability Analyzer的底层依赖，可在自定义Roslyn分析器中直接调用兼容性检查逻辑
• 编写Roslyn语法分析器，遍历项目所有代码文件的语法节点（如InvocationExpressionSyntax、ObjectCreationExpressionSyntax等），对每个成员调用/类型实例化，通过Portability库检查是否属于.NET 6不兼容项
• 一旦匹配到不兼容成员，直接记录其所在的文件路径、行号、代码内容，生成结构化报告（JSON/CSV）

示例核心逻辑片段：

// 初始化Portability规则集，目标框架设为.NET 6
var rules = new PortabilityRuleSet(TargetFrameworkMonikers.Net60);
var analyzer = new PortabilityAnalyzer(rules);

// 遍历语法树中的成员调用
public override void VisitInvocationExpression(InvocationExpressionSyntax node)
{
    var symbol = SemanticModel.GetSymbolInfo(node).Symbol as IMethodSymbol;
    if (symbol == null) return;
    
    // 检查该方法是否不兼容.NET 6
    var issues = analyzer.AnalyzeSymbol(symbol);
    if (issues.Any())
    {
        // 记录位置信息
        var location = node.GetLocation();
        var filePath = location.SourceTree.FilePath;
        var lineNumber = location.GetLineSpan().StartLinePosition.Line + 1;
        // 写入报告
        ReportIssue(filePath, lineNumber, symbol.ToString(), issues.First().Message);
    }
    base.VisitInvocationExpression(node);
}

二、优化现有Portability Analyzer工作流 #

如果你不想从零编写Roslyn分析器，可对现有Portability Analyzer的输出做二次处理：

• 用Portability Analyzer导出XML格式的兼容性报告，提取其中所有不兼容的类型/成员全名（如System.AppDomainSetup..ctor、System.Web.UI.Control）
• 编写简单的代码扫描脚本（如用PowerShell、Python或Roslyn的命令行工具dotnet roslynator analyze），批量搜索项目源代码中匹配这些全名的调用位置
• 脚本可输出包含文件、行号的结果，方便定位

三、CI/CD集成与PR差异对比 #

为了跟踪迁移进度和管控PR新增的不兼容调用：

• 将分析工具打包为命令行应用，在CI流水线中作为独立步骤运行，输出结构化的JSON报告
• 保存每次运行的报告，用脚本（如jq）对比当前PR报告与基线报告的差异，筛选出新增的不兼容条目
• 在CI中设置规则：若PR新增了不兼容调用，触发警告或直接阻止合并，确保迁移进度正向推进

补充说明 #

• 针对ASP.NET Web Forms这类Upgrade Assistant未覆盖的场景，上述方案可通过直接扫描System.Web.UI命名空间下的类型调用，精准定位所有不兼容代码
• 若项目规模极大，可考虑增量扫描：仅分析PR中变更的文件，减少CI运行时间

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