分析器：常见问题-Toy模板网

这篇具有很好参考价值的文章主要介绍了分析器：常见问题。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

title: 分析器：常见问题
date: 2022-04-03
tags:
- C#
- .NET
- Roslyn

前言

源生成器（增量生成器）由于它特殊的定位，关于它的调试十分困难。在这里分享一些调试它的经验。

另外经常有写类库，然后提供可以生成代码的Attribute给用户的需求，此时需要用到传递引用的知识点。

调试源生成器

源生成器执行时间

源生成器项目和普通的项目不同。

普通的会在你按下运行或调试后才会运行；而源生成器会在两种情况下运行：

重新生成解决方案或该项目时候运行，运行后会生成dll文件。在下一次启动VS的时候，会连着dll一起读取，所以可能会有VS找不到生成的文件导致报错，但可以正常运行的问题，重启VS即可。

在生成项目后第二次及以后打开项目时，每次对代码进行更改都会重新运行源生成器的dll，并实时将生成的代码加入到项目中。所以源生成器的执行效率很大程度关乎用户的编程手感。

以下程序段默认引用命名空间：

using System.Diagnostics;

启动调试器

在源生成器项目中，直接在Visual Studio用鼠标点击行号左边打的（红色圆形的）断点是没有用的，需要添加一条Debugger.Launch();，表示启动了调试器。

如果程序运行到这条语句时，会弹出一个窗口，选择调试的程序：

分析器：常见问题

建议选择自己的项目（在此图的第二个）即可。

点击OK后程序会停在Debugger.Launch();处，此时可以插入Debugger.Break();或直接鼠标点击插入断点。

如果要启动调试器，Debugger.Launch();一定要放在源生成器刚开始的位置，而且不要插入多个，尤其不能插在多次执行的程序块内（如循环）；若有需要可在其中打断点，否则第二次打开VS会一直弹窗。

生成中关闭调试器

有时运行一半时发现问题无需继续调试时，需要关闭调试器。但简单地终止调试可能无效，因为可能遇到另一个Debugger.Launch();。

所以我们需要先停止生成，再关闭调试器。

生成→取消
（如果调试器没有关闭）调试→停止调试

关闭Visual Studio前

关闭之前我们应该先把Debugger.Launch();删除或注释掉，并重新生成项目，以免下次打开VS的时候自动弹出调试器窗口。

类库中分析器的传递引用

从引用项目时的方式就可以看出，生成器项目本身是作为分析器（Analyzer）项目引入的：

<ItemGroup>
    <ProjectReference Include="XXX.SourceGenerator.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" />
</ItemGroup>

此时类库项目引用了源生成器项目，类库项目又被用户项目引用，那么问题是用户项目可以被源生成器生成代码吗？

答案一般是不能。

如果要实现这种效果，那需要满足两个条件：

类库项目应作为NuGet包被引用，而非项目引用。
类库项目将分析器包含进NuGet包。

综上，我们应该在生成NuGet包的项目内这样写：

<ItemGroup>
    <ProjectReference Include="XXX.SourceGenerator.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" />
    <None Include="XXX.SourceGenerator.dll" Pack="true" PackagePath="analyzers/dotnet/cs" Visible="false" />
</ItemGroup>

其中XXX.SourceGenerator.dll是源生成器项目的输出文件路径。

在引用该NuGet包之后，除了可以使用生成器外，其他该NuGet项目引用的类型也可以访问，这就是所谓“传递引用”。

其中ReferenceOutputAssembly="false"是指虽然引用分析器的输出，但不引用他的类型（如class XXXGenerator）。

注：如果项目没有使用NuGet包的必要，并且可以实现项目引用，又有此类需求；则可以简单地让用户项目按分析器引用源生成器项目即可。

分析器简介

本文分析器主要指以“Analyzer”模式引用的项目或NuGet包，例如源生成器（source generator）、代码分析器（analyzer）、代码修复器（codefixer）等

注：其中源生成器和代码分析器的“血缘关系”更近，可能因为都是.NET使用的分析器，而代码修复器是提供给Visual Studio使用的，所以关系疏远一些

分析器引用别的项目时的问题

根据MSDN和Visual Studio自带的代码示例，所有分析器和源生成器都必须包含以下两个库：

Microsoft.CodeAnalysis.CSharp
Microsoft.CodeAnalysis.Analyzers

所有代码修复器都必须包含以下这个库：

Microsoft.CodeAnalysis.CSharp.Workspaces

肯定不止我一个人（bushi）想到，为什么不把一些最简单的类型、或者一些工具库给所有的分析器共享呢？这样引用时就不需要写字符串而是nameof(xxx)了，多优雅。

可惜由于分析器项目的限制，除了以上说的必须包含的库，其他库都不能很方便地引用。但这也不是说每次写分析器都要手动实现.NET的新特性，Sergio Pedri^[1]大佬实现了Poly#^[2]（PolySharp）库，这个库实现了绝大部分可以实现的特性，并且可以被分析器项目“引用”。因为它是把所有需要的代码生成到你的项目里，而非直接引用，所以绕过了分析器不能引用项目的限制。

引用这个库的方法和其他库一样，在NuGet里下载并添加包引用即可。

如果想要引用其他NuGet包（如System.Text.Json），可以参考我的这篇文章：《分析器/源生成器添加项目依赖的方式》

目标平台问题

分析器项目与普通项目不同，分析器本身的dll不会被用户项目直接引用，而是被编译平台（如.NET SDK或Visual Studio等）引用，从而对代码进行分析。所以分析器本身的dll不会被包含进用户项目生成的应用里（源生成器生成的代码会）

既然分析器的dll是被编译平台引用而非用户项目，那源生成器的目标平台就应该与编译平台有关，而非用户项目。例如，在x64架构的电脑上编译x86的应用程序，此时一般的用户项目目标平台都应该设置为x86，但分析器项目的目标平台却应该与电脑保持一致（x64），因为编译项目时，是电脑上x64的.NET SDK调用了分析器项目。

为了保证项目编译的可移植性，如何判断编译电脑的架构并设置为对应平台呢？此时简单地将目标平台设为AnyCPU即可，AnyCPU正是根据自身电脑架构获取的目标平台。

又如使用GitHub Action时，分析器项目经常会遇到如下错误（CS8034）：

CSC : warning CS8034: Unable to load Analyzer assembly D:\a\xxx.SourceGenerator\bin\x86\Debug\netstandard2.0\xxx.SourceGenerator.dll : Unable to load xxx.SourceGenerator [D:\a\xxx.csproj]

这显然是因为目标平台设置错误，但使用Visual Studio手动编译就没有问题，sln文件里的平台映射（platform map）也确实是AnyCPU啊？这是因为解决方案的平台映射不一定会被所有地方遵循，最稳妥的方案是在csproj文件里指定目标平台。故在分析器项目中加上如下一行（PlatformTarget）即可：

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        ...
        <PlatformTarget>AnyCPU</PlatformTarget>
        ...
    </PropertyGroup>
    ...
</Project>

不过为了直接运行也不出错，建议平台映射里的AnyCPU也要保留。

IDE兼容性问题

既然分析器是被编译平台调用，那分析器的Roslyn版本也要与编译平台一致。

所有源生成器和代码分析器都会引用以下的库。

Microsoft.CodeAnalysis.CSharp

而代码修复器则会使用

Microsoft.CodeAnalysis.CSharp.Workspaces

这两个库的版本都和Roslyn的版本相同（截至本文发布，是4.6.0），而Visual Studio的版本也是相关（VS2022的版本目前是VS 17.6.xxx）。所以如果使用了4.6.0的Roslyn，低于17.6.xxx版本的VS就无法使用了。例如VS2022的版本号是VS 17.xxx，VS2019的版本号是VS 16.xxx。如果编写的分析器需要有较为广泛的兼容性，可能需要降低版本，放弃新特性