Add a hack to remove output from the Razor generator if suppressed#61675
Merged
jasonmalinowski merged 1 commit intodotnet:release/dev17.3from Jun 6, 2022
Conversation
davidwengier
approved these changes
Jun 3, 2022
Member
|
Random question @jasonmalinowski: When Ryan and I were debugging this we could see the source generated documents in the analyzers tree in Solution Explorer. It didn't click at the time, but that was probably the sign that things were wrong, because that is unexpected, correct? And if so, does this fix remove them again? |
Member
Author
|
@davidwengier Yes, "unfortunately" -- that would have been a hint indeed that something was wrong/changed from before. |
9e6bc43 to
baee87f
Compare
src/Workspaces/Core/Portable/Workspace/Solution/SolutionState.CompilationTracker.cs
Outdated
Show resolved
Hide resolved
CyrusNajmabadi
approved these changes
Jun 3, 2022
jasonmalinowski
added a commit
to jasonmalinowski/sdk
that referenced
this pull request
Jun 3, 2022
dotnet#24928 made a change to the Razor generator to ensure that even if the generator is suppressed, it's still going to run and cache it's outputs so later runs aren't a from-scratch run on a performance-critical path. However, a bug meant that if the generator was suppressed, it'd still run the first time it's invoked, and will still output files even though it was supposed to be suppressed. The approach taken here is to suppress the addition of the files, but at the very end of the chain only -- the generation and walking in the middle of the incremental chain is left untouched, so that still has the existing caching behavior. This fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1545938 but we're still considering dotnet/roslyn#61675 as a tactical fix instead.
The Razor generator is controlled by a flag that lives in an .editorconfig file; in the IDE we generally don't run the generator and instead use the design-time files added through the legacy IDynamicFileInfo API. When we're doing Hot Reload we then remove those legacy files and remove the .editorconfig file that is supposed to disable the generator; for the Hot Reload pass we then are running the generator. This is done in the CompileTimeSolutionProvider. dotnet/sdk#24928 introduced an issue where even though the Razor generator is being told to not run, it still runs anyways. As a tactical fix rather than reverting that PR, for Visual Studio 17.3 Preview 2 we are going to do a hack here which is to rip out generated files. In discussion, simply reverting the SDK change was problematic because it would reintroduce some notable performance issues that it was intended to fix in the first place. Fixing the generator directly is also possible (and we'll be doing a follow-up PR to try doing that), but is also a fairly risky change given the amount of testing that was required to test the PR in the first place. This we think is the least-risky option we have, even though it itself is touching a fairly sensitive area of our codebase. The intent is to remove this hack by Preview 3 with a properly tested fix in the generator.
baee87f to
59e3918
Compare
Member
Would adding a manual check for the presence of files under the Analyzers node be a good early warning sign, to avoid the long investigation through multiple teams to track this down? Or is it no better a signal than "the whole document has red squiggles" which got us here? |
Member
Author
@davidwengier Yes, potentially, but the red squiggles all about ambiguous types was also a pretty good giveaway if you know how this system is supposed to work too. We're also updating tests for the generator properly in dotnet/sdk#25833 so long investigations don't happen either. 😄 |
jasonmalinowski
added a commit
to jasonmalinowski/sdk
that referenced
this pull request
Jun 16, 2022
dotnet#24928 made a change to the Razor generator to ensure that even if the generator is suppressed, it's still going to run and cache it's outputs so later runs aren't a from-scratch run on a performance-critical path. However, a bug meant that if the generator was suppressed, it'd still run the first time it's invoked, and will still output files even though it was supposed to be suppressed. The approach taken here is to suppress the addition of the files, but at the very end of the chain only -- the generation and walking in the middle of the incremental chain is left untouched, so that still has the existing caching behavior. This fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1545938 but we're still considering dotnet/roslyn#61675 as a tactical fix instead.
jasonmalinowski
added a commit
to jasonmalinowski/razor-compiler
that referenced
this pull request
Jun 16, 2022
dotnet/sdk#24928 made a change to the Razor generator to ensure that even if the generator is suppressed, it's still going to run and cache it's outputs so later runs aren't a from-scratch run on a performance-critical path. However, a bug meant that if the generator was suppressed, it'd still run the first time it's invoked, and will still output files even though it was supposed to be suppressed. The approach taken here is to suppress the addition of the files, but at the very end of the chain only -- the generation and walking in the middle of the incremental chain is left untouched, so that still has the existing caching behavior. This fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1545938 but we're still considering dotnet/roslyn#61675 as a tactical fix instead.
jasonmalinowski
added a commit
to jasonmalinowski/razor-compiler
that referenced
this pull request
Jun 16, 2022
dotnet/sdk#24928 made a change to the Razor generator to ensure that even if the generator is suppressed, it's still going to run and cache it's outputs so later runs aren't a from-scratch run on a performance-critical path. However, a bug meant that if the generator was suppressed, it'd still run the first time it's invoked, and will still output files even though it was supposed to be suppressed. The approach taken here is to suppress the addition of the files, but at the very end of the chain only -- the generation and walking in the middle of the incremental chain is left untouched, so that still has the existing caching behavior. This fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1545938 properly; dotnet/roslyn#61675 was put in as a tactical fix first.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Razor generator is controlled by a flag that lives in an .editorconfig file; in the IDE we generally don't run the generator
and instead use the design-time files added through the legacy IDynamicFileInfo API. When we're doing Hot Reload we then
remove those legacy files and remove the .editorconfig file that is supposed to disable the generator; for the Hot Reload pass we then are running the generator. This is done in the CompileTimeSolutionProvider.
dotnet/sdk#24928 introduced an issue where even though the Razor generator is being told to not run, it still runs anyways. As a tactical fix rather than reverting that PR, for Visual Studio 17.3 Preview 2 we are going to do a hack here which is to rip out generated files. In discussion, simply reverting the SDK change was problematic because it would reintroduce some notable performance issues that it was intended to fix in the first place. Fixing the generator directly is also possible (and we'll be doing a follow-up PR to try doing that), but is also a fairly risky change given the amount of testing that was required to test the PR in the first place. This we think is the least-risky option we have, even though it itself is touching a fairly sensitive area of our codebase.
The intent is to remove this hack by Preview 3 with a properly tested fix in the generator.
This is a tactical fix for https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1545938