Using EmitCompilerGeneratedFiles and CompilerGeneratedFilesOutputPath to keep track of generated files on source control

[MulletPr00f]

I'm using this configuration in my *.csproj:

<EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
<CompilerGeneratedFilesOutputPath>GEN_PATH</CompilerGeneratedFilesOutputPath>

I have a few questions:

1. Is there a way to emit generated files only to one specific generator referenced in the project? I don't want to do that to all generators, definitely not to the generators I'm not responsible for, such as the default generators referenced by the Microsoft SDKs.

2. Is there a way to set CompilerGeneratedFilesOutputPath to a relative path of the input file? Examples:

• \Directory_A\File_A.ext would generate the file \Directory_A\File_A.generated.ext.cs
• \Directory_B\File_B.ext would generate the file \Directory_B\File_B.generated.ext.cs

[333fred]

1. No, we haven't found any need for this. Can you elaborate on why you care to output some generators, but not all?
2. No.

[MulletPr00f]

Sorry, I think you misundestood me. You said "EmitCompilerGeneratedFiles does not control whether generators are run.". Yes, absolutely. But if I enable it and keep the generated files on source control, I can disable the code generation on release configuration.

Let's say I have a code generation library called MyGenerators that generates source code files using as input *.razor files. I'm using it on a client project called MyProject, which has only 27 *.razor files at the moment, but will probably grow to hundreds of *.razor files. Related to MyProject there are some scenarios:

Scenario A
ProjectReference: no reference to MyGenerators.
Build config: Debug.
Build result:

========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
========== Build completed at 2:02 AM and took 03.195 seconds ==========

After build: no generated files.

Scenario B
ProjectReference: reference to MyGenerators without any condition.
EmitCompilerGeneratedFiles: false.
Build config: Debug (Release times are very similar)
Build result:

========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
========== Build completed at 2:05 AM and took 11.423 seconds ==========

After build: 27 generated files.

Scenario C
ProjectReference: reference to MyGenerators without any condition.
EmitCompilerGeneratedFiles: true
Build config: Debug
Build result:

========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
========== Build completed at 2:13 AM and took 11.711 seconds ==========

After build: 27 generated files that can (and will) be added to source control by some developer.

Scenario D (Release - automated build)
ProjectReference: reference to MyGenerators with condition $(Configuration)'=='Debug'.
EmitCompilerGeneratedFiles: true
Build config: Release
Build result:

========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
========== Build completed at 2:16 AM and took 04.237 seconds ==========

After build: no generated files by the build itself. But I already have 27 generated files that were previously added to source control.

You can notice an increase in the build time when MyGenerators is referenced. It's not much for a single project in one developer's machine, with a small number of input files, but my concern is Scenario B with Release configuration on an automated build, with hundreds of input files to be generated.

The problem is how the CI pipeline of automated build works: it creates a temporary solution with the modified projects (and if it's references are added as project references, those projects also). So it will always generate those source code files, cause the files are always new to the workspace. Incremental generation won't matter on this scenario, only on a dev's machine. Regarding the pipeline itself, it can have a lot of integration processes, like unit testing, health checks, so it will take longer than just a build to run. Let's say a small project will take something around 3-5 minutes to finish a pipeline. This pipeline get's triggered on every developer's check-in in the source control, and only starts when the previous has finished. So having these generated files not being generated on a release build, but added to the source control and built like regular *.cs files, would mitigate this decrease of performance.

So, having said that and considering this time penalty, I think Roslyn source code generators as it is maybe aren't the best choice for our environment.

A workaround could be not calling context.AddSource on my source output action, and just disabling RS1035 and creating a *.cs file by hand on a desired path of my choice, and add that file to source control, idk.

[333fred]

I'd say that the first step is investigating which generators are taking up that time. You can use https://github.com/dotnet/roslyn/blob/main/docs/analyzers/Report%20Analyzer%20Format.md to add analyzer timing information to a binlog; you can then use that to start looking into which generators are taking up time. IMO, attempting to have generators automatically run in DEBUG mode, but then not in RELEASE, is just setting you up for a world of pain and unintentional footguns of "well, it worked on my machine", because someone forgot to do a complete DEBUG build locally and check in updated generated files.

[333fred]

Oh, and absolutely do not disable RS1035 and do IO in your generator. This will break your build's up-to-date checking, as well as your VS experience. The compiler has discussed ways to actually block IO in generators and analyzers, and we may be much harder on it in the future.

[MulletPr00f]

You can use https://github.com/dotnet/roslyn/blob/main/docs/analyzers/Report%20Analyzer%20Format.md to add analyzer timing information to a binlog; you can then use that to start looking into which generators are taking up time.

I'll try that. Even though there's only one generator in this project reference and it does nothing special, it's generating an empty class.

IMO, attempting to have generators automatically run in DEBUG mode, but then not in RELEASE, is just setting you up for a world of pain and unintentional footguns of "well, it worked on my machine", because someone forgot to do a complete DEBUG build locally and check in updated generated files.

I get your point, but that shouldn't really happen in this case, as it would break the build if a generated file doesn't exist. It would be a partial class that's generated and supposed to have implementation used in *.razor or *.razor.cs files.

[jasonmalinowski]

it would break the build if a generated file doesn't exist. It would be a partial class that's generated and supposed to have implementation used in *.razor or *.razor.cs files.

The scary bit wouldn't be a missing file, but a file that is stale in some way or another in a way that compiles (since the methods are fine) but the contents are off. Then you end up code that works fine locally but fails in production or whatever.