ProjectChanged Events Triggered More Often #74058
Comments
dotnet-issue-labeler
bot
added
Area-IDE
untriaged
ToddGrun
added a commit
to ToddGrun/roslyn
that referenced
this issue
Jun 25, 2024
Addresses dotnet#74058 LiveUnitTest team reported a fairly recent regression where Roslyn started reporting Project changed workspace events during file addition / removal. This causes the LUT window to unnecessarilly rerun tests. This regressed as part of a change I made back in March around passing in a temp path to the compiler's strong name provider, as otherwise an EmitStream call fails, breaking intellisense in projects using assembly signing. (Change here: dotnet#72587) The regression is due to me changing several callers to creating a strong name provider based on the path, instead of them all using the default instance. With the previous behavior, equality checks on these newly created StrongNameFileSystem and DesktopStrongNameProvider instances would return false, even though the temp path in the file systems were the same. It's a bit of a windy path to how this relates to the LUT window. The Roslyn ProjectSystemProject.ChangeProjectProperty call is the crux of where the issue was being exposed. UpdateProjectOptions_NoLock was calling it with a new DesktopStrongNameProvider created with the temp path as outlined above. ChangeProjectProperty checks the old value of the strong name provider against the newValue, and if they are the same, it doesn't add anything to the batched events it will later send out. However, in this case, the equality check failed, so we started sending out a project changed notification, breaking the LUT behavior. The fix here is to simply implement Equals in StrongNameFileSystem, and have DesktopStrongNameProvider use that instead of just checking for reference equality.
ToddGrun
added a commit
that referenced
this issue
Jun 28, 2024
* Better detect equivalence in our strong name provider Addresses #74058 LiveUnitTest team reported a fairly recent regression where Roslyn started reporting Project changed workspace events during file addition / removal. This causes the LUT window to unnecessarilly rerun tests. This regressed as part of a change I made back in March around passing in a temp path to the compiler's strong name provider, as otherwise an EmitStream call fails, breaking intellisense in projects using assembly signing. (Change here: #72587) The regression is due to me changing several callers to creating a strong name provider based on the path, instead of them all using the default instance. With the previous behavior, equality checks on these newly created StrongNameFileSystem and DesktopStrongNameProvider instances would return false, even though the temp path in the file systems were the same. It's a bit of a windy path to how this relates to the LUT window. The Roslyn ProjectSystemProject.ChangeProjectProperty call is the crux of where the issue was being exposed. UpdateProjectOptions_NoLock was calling it with a new DesktopStrongNameProvider created with the temp path as outlined above. ChangeProjectProperty checks the old value of the strong name provider against the newValue, and if they are the same, it doesn't add anything to the batched events it will later send out. However, in this case, the equality check failed, so we started sending out a project changed notification, breaking the LUT behavior. The fix here is to simply implement Equals in StrongNameFileSystem, and have DesktopStrongNameProvider use that instead of just checking for reference equality.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version Used:
VS 17.10.1
Microsoft.CodeAnalysis.Workspaces.Common 4.5.0-2.22567.8
Description: Creating/removing files is triggering ProjectChanged events.
Steps to Reproduce:
Expected Behavior: Only DocumentAdded/DocumentChanged events are triggered.
Actual Behavior: DocumentAdded/DocumentChanged/ProjectChanged are all triggered.
The text was updated successfully, but these errors were encountered: