C# Roslyn生成器与文件 C#如何使用Source Generator在编译时生成代码文件

来源:这里教程网 时间:2026-02-21 17:43:21 作者:

Source Generator 生成的代码能写入磁盘文件吗

不能。Source Generator 的核心限制就是:它只能向编译器提供

SourceText
,不能创建或写入磁盘上的 .cs 文件。你看到的“生成代码”,其实是被编译器临时加载进当前编译单元的字符串内容,不会落地为项目里的物理文件。

常见错误现象是,在 Generator 里用

File.WriteAllText
Directory.CreateDirectory
尝试保存文件——这要么静默失败(因编译器沙箱限制),要么在 MSBuild 过程中抛出
UnauthorizedAccessException
NotSupportedException

使用场景上,Generator 只适用于“参与编译”的需求:比如根据

[MyAttribute]
自动生成类型成员、补全接口实现、注入日志代码等。它不是代码模板工具,也不替代 T4 或 dotnet-sourcelink 这类文件生成器。

想让生成的代码出现在项目里,该怎么做

必须把生成的内容通过

context.AddSource
注入编译流程,由 Roslyn 自动参与后续解析、语义分析和 IL 生成。

context.AddSource("MyGenerated.g.cs", SourceText.From(content, Encoding.UTF8))
是唯一合法入口;文件名后缀建议用
.g.cs
(约定俗成,且能被 IDE 自动折叠)
生成的字符串必须是合法 C# 语法,且不能有编译错误,否则整个项目编译失败(不是警告) 不要拼接带 BOM 的字符串,
SourceText.From
默认不带 BOM;若手动读取模板再替换,记得用
Encoding.UTF8
显式指定,避免编码错乱导致中文注释变乱码
生成的类/成员必须满足命名空间与可见性规则:比如生成
internal
类时,确保宿主项目没开启
InternalsVisibleTo
外部访问需求,否则调用方看不到

为什么不能直接生成 .cs 文件到项目目录

Roslyn 编译是无状态、可重现的:每次构建都应从相同输入产出相同输出。如果 Generator 擅自写磁盘文件,会导致增量编译失效、CI 环境行为不一致、Git 脏工作区等问题。

性能影响很实际:磁盘 I/O 会拖慢编译速度,而 Generator 设计目标是在毫秒级完成(通常要求 AD0001(Analyzer took longer than expected)。

兼容性方面,.NET SDK 6+ 的默认编译模式(

UseSharedCompilation=false
)下,Generator 运行在受限的
AssemblyLoadContext
中,对
System.IO
的多数 API 是禁用的——不是你不小心,而是 runtime 根本不让你调。

那调试 Generator 生成的代码很难看?

确实难,但有路可走。生成的

.g.cs
不会出现在 Solution Explorer,但可在调试时通过以下方式确认内容:

在 Generator 里加断点,把
content
字符串复制出来,粘贴到临时 .cs 文件里手动检查语法
启用
dotnet build -bl
生成
msbuild.binlog
,用 MSBuild Structured Log Viewer 查看 “Source Generators” 节点下的输出源码
在项目文件中添加
<emitcompilergeneratedfiles>true</emitcompilergeneratedfiles>
,编译后会在
obj/Debug/netX.X/generated/
下看到实际注入的文件(仅用于调试,勿提交)

最容易被忽略的一点:Generator 的执行时机在语法树绑定前,所以它看不到语义信息(比如某个

INamedTypeSymbol
是否实现了某接口),只能靠语法树遍历 + 属性标记推断。想做深度语义生成,得配合
ISymbol
分析,但必须确保符号已成功解析——否则拿到的是 null,不是报错。

相关推荐

热文推荐