2026-03-22
第 1 篇为什么 AdditionalFiles 才是第二阶段真正的开始
当生成器开始读取 AdditionalFiles、MSBuild 元数据和项目默认值时,它就不再只是演示案例,而是开始接近真实工程输入。
系列
第二季主线:把输入从源码扩展到 AdditionalFiles、MSBuild 元数据和项目级默认值,进入更接近工程实践的生成器形态。
这一季不再只讨论源码里的特性和类型符号,而是把输入正式扩展到:
AdditionalFiles 文件内容CompilerVisibleItemMetadata 暴露的文件级元数据CompilerVisibleProperty 暴露的项目级默认值先把 AdditionalFiles、MSBuild 元数据和项目默认值看成同一套编译期输入系统。
先分清文件内容、文件元数据和项目级默认值各自负责什么,不要一开始就混成一层。
真正难的不是读取文件,而是多文件并组、覆盖优先级和输出对象边界如何稳定。
再处理目录约定、前缀修剪和显式启用,把第二案例推进到能接旧项目的状态。
如果你已经读完第一季,这一季就是把生成器从教程样例推进到工程形态的下一步。
2026-03-22
第 1 篇当生成器开始读取 AdditionalFiles、MSBuild 元数据和项目默认值时,它就不再只是演示案例,而是开始接近真实工程输入。
2026-03-22
第 2 篇很多人以为命名空间、类名和可见性都应该写在 JSON 里,但第二案例里,这些单文件覆盖项更适合来自 AdditionalFiles 元数据。
2026-03-22
第 3 篇项目级默认命名空间、类名和可见性不是便利配置而已,它们会直接改变生成器的输出契约和回退路径。
2026-03-22
第 4 篇第二案例最难稳住的不是把 JSON 读进来,而是多个输入文件如何合法地并成同一个输出类型。
2026-03-22
第 5 篇第二季真正把难度拉高的,不是又多读了几个 JSON,而是多个输入文件怎样稳定地并成同一个输出目标。
2026-03-22
第 6 篇第二案例里,多输出组并存不是额外能力,而是分组键稳定之后自然出现的结果。
2026-03-22
第 7 篇当目录约定进入第二案例后,目录层级不再只是文件组织方式,而会正式进入生成器的命名空间决议。
2026-03-22
第 8 篇前缀裁剪不是为了少打一段字符串,它真正解决的是共享资源键命名和最终生成 API 之间的边界污染。
2026-03-22
第 9 篇当生成器支持显式文件发现后,命名约定就不再是唯一入口,这一步才让第二案例真正适合接旧项目。