Add MSBuild project to solution and apply the change to Roslyn workspace as a unit #2314
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.
I often hit 'Failed to add project to workspace: ' error in OmniSharp log when opening one of internal projects. I only see this issue on Linux (Ubuntu 20.04) and not on Windows. I always have omnisharp.enableMsBuildLoadProjectsOnDemand set to "true". The problem occurs often but not all the time.
In both success and failure cases I see the following sequence of events (shortened to highlight only important parts):
In the case of the failure though the sequence is followed by:
The documentation for "bool Workspace.TryApplyChanges(Solution newSolution)" states: “… The specified solution must be one that originated from this workspace. If it is not, or the workspace has been updated since the solution was obtained from the workspace, then this method returns false …"
ProjectManager.AddProject clearly passes the solution that is originated from the same workspace. Therefore, the workspace somehow gets changed b/w adding the project to the solution and applying the changes to the workspace. The theory is that the file change notification received for ProjectName.AssemblyInfo.cs causes the workspace change in ProjectManager.OnDirectoryFileChanged. Thus, the lock added around these two places. My testing shows that the change does address the issue I'm seeing.