Avoid transforming solution for Hot Reload when Razor's ForceRuntimeCodeGeneration feature flag is enabled #77221
Conversation
dotnet-issue-labeler
bot
added
Area-IDE
untriaged
tmat
changed the title
|
|
||
| if (legacyOverrideSuppressRazorSourceGenerator) | ||
| { | ||
| entries = entries.SetItem("build_property.SuppressRazorSourceGenerator", "false"); |
There was a problem hiding this comment.
I don't understand this bit. Why do we want to allow the generator to run if forceRuntimeCodeGen is on? Seems like that would break Razor IDE scenarios, because the IDE is going to provide C# via IDynamicFileInfoProvider, and the source generator will provide the same C#.
There was a problem hiding this comment.
We need to run the source generator for Hot Reload. Do we need to disable IDynamicFileInfoProvider if forceRuntimeCodeGen then?
There was a problem hiding this comment.
That would definitely break the IDE.
Maybe I'm missing context here, it this feels like the PR we would want for cohosting, once dotnet/razor#11412 is merged for example. That PR does indeed turn off IDynamicFilInfo in favour of the generator. Cohosting is a different feature flag though.
Force runtime code generation doesn't fundamentally change how Razor works in the IDE, it just makes the code generated look the same as what the source generator produces.
There was a problem hiding this comment.
I see, so we will need cohosting as well to make this work.
Aims to avoid overhead of a separate solution snapshot used for Hot Reload and EnC.
The feature flag is checked at two locations:
build_property.SuppressRazorSourceGeneratorif the feature flag is enabled. The option is set in an editorconfig file included to all Razor projects by Razor SDK and defaults to true. When the solution was transformed in CompileTimeSolutionProvider the editorconfig file was removed, which enabled the source generator. If the transformation is not performed the source generator would be disabled if we didn't override the option.IDynamicFileInfoProvider