Problems list broken when Roslyn Analyzer is enabled

[chis-j]

Problems list is only showing issues from files just opened in editor if "Roslyn Analyzer" is enabled and "Analyze Open Documents Only" is disabled. This is true for Errors, Warnings and Infos (which are all not filtered in the problems list). Note: "Max Project File Count For Diagnostic Analysis" is set much higher than the actual file count and does not even show any effect when set to 0 or negative.

Steps to Reproduce

Settings:

  "omnisharp.useModernNet": true,
  "omnisharp.enableRoslynAnalyzers": true,
  "csharp.maxProjectFileCountForDiagnosticAnalysis": 10000

Expected Behavior

All Errors, Warnings and Infos across all *.cs files in the workspace are listed under problems.

Actual Behavior

Any Errors, Warnings and Infos of one *.cs file are listed only once that file has been opened in editor. (Any errors in files not being opened are never being listed.) Once "omnisharp.enableRoslynAnalyzers": false is set - all errors are listed again as expected.

OmniSharp log

Starting OmniSharp server at 4/14/2022, 10:39:08 AM Target: d:\proj\xxx

OmniSharp server started with .NET 6.0.103 . Path: c:\Users\chr.vscode\extensions\ms-dotnettools.csharp-1.24.4-win32-x64.omnisharp\1.38.2-net6.0\OmniSharp.dll PID: 12388

Starting OmniSharp on Windows 10.0.19044.0 (x64) info: OmniSharp.Services.DotNetCliService Checking the 'DOTNET_ROOT' environment variable to find a .NET SDK info: OmniSharp.Services.DotNetCliService Using the 'dotnet' on the PATH. info: OmniSharp.Services.DotNetCliService DotNetPath set to dotnet info: OmniSharp.MSBuild.Discovery.MSBuildLocator Located 1 MSBuild instance(s) 1: .NET Core SDK 6.0.103 17.0.0 - "C:\Program Files\dotnet\sdk\6.0.103" info: OmniSharp.MSBuild.Discovery.MSBuildLocator Registered MSBuild instance: .NET Core SDK 6.0.103 17.0.0 - "C:\Program Files\dotnet\sdk\6.0.103" info: OmniSharp.WorkspaceInitializer Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpFormattingWorkspaceOptionsProvider, Order: 0 info: OmniSharp.MSBuild.ProjectManager Queue project update for ... ... info: OmniSharp.WorkspaceInitializer Configuration finished. info: OmniSharp.Stdio.Host Omnisharp server running using Stdio at location 'd:\proj\xxx' on host 14932. info: OmniSharp.MSBuild.ProjectManager Loading project: ... ... info: OmniSharp.Roslyn.CSharp.Services.Diagnostics.CSharpDiagnosticWorkerWithAnalyzers Solution initialized -> queue all documents for code analysis. Initial document count: 286.

Environment information

VSCode version: 1.66.2 C# Extension: 1.24.4

Dotnet Information

.NET SDK (reflecting any global.json): Version: 6.0.103 Commit: 2d7bc7059f

Runtime Environment: OS Name: Windows OS Version: 10.0.19044 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\6.0.103\

Host (useful for support): Version: 6.0.3 Commit: c24d9a9c91

.NET SDKs installed: 1.1.4 [C:\Program Files\dotnet\sdk] 2.1.300 [C:\Program Files\dotnet\sdk] 2.1.805 [C:\Program Files\dotnet\sdk] 2.1.818 [C:\Program Files\dotnet\sdk] 3.1.405 [C:\Program Files\dotnet\sdk] 3.1.417 [C:\Program Files\dotnet\sdk] 5.0.212 [C:\Program Files\dotnet\sdk] 6.0.103 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.All 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 1.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 1.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 3.1.23 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 5.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 6.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs: https://aka.ms/dotnet-download

Visual Studio Code Extensions

Extension	Author	Version
cpptools	ms-vscode	1.9.7
csharp	ms-dotnettools	1.24.4
data-workspace-vscode	ms-mssql	0.1.1
gitlens	eamodio	12.0.6
json-pretty-printer	euskadi31	1.1.0
jupyter	ms-toolsai	2022.3.1000901801
jupyter-keymap	ms-toolsai	1.0.0
jupyter-renderers	ms-toolsai	1.0.6
live-html-previewer	hdg	0.3.0
mssql	ms-mssql	1.13.0
python	ms-python	2022.4.1
sql-database-projects-vscode	ms-mssql	0.14.1
swagger-viewer	Arjun	3.1.2
vscode-arduino	vsciot-vscode	0.4.11
vscode-commons	redhat	0.0.6
vscode-docker	ms-azuretools	1.21.0
vscode-postgresql	ms-ossdata	0.3.0
vscode-pylance	ms-python	2022.4.1
vscode-xml	redhat	0.20.0
vscode-yaml	redhat	1.6.0
xslt-xpath	deltaxml	1.2.3

output from your clipboard

[JoeRobich]

@chis-j Do you have an omnisharp.json in your solution folder or your user directory that might have "AnalyzeOpenDocumentsOnly" set to true?

[chis-j]

@JoeRobich No, I double checked that there is no "AnalyzeOpenDocumentsOnly" in any omnisharp.json

[babula38]

Having the same issue.

[gyantal]

Me too. Having the same problem.

[rjgotten]

Same here. Exact same symptoms.

Went through available public versions to install to bisect.

Works up through version 1.24.1 of the C# extension. Broken as of 1.24.2 - the very version that added the AnalyzeOpenDocumentsOnly feature. Now, I'm not one to point fingers, but you have to admit: that would be a very, very freak coincidence if not related, no? 😉

Technical details VSCode version: 1.68.1 C# Extension: [ 1.24.2, ... ) .NET SDK: 6.0.301

[Dryadxon]

I did a git bisect today after learning about this issue, and thanks to @rjgotten it was really quick to do. The culprit of this problem seems to be the commit 6c306e8888be4f53423d7f4d253777e53c661ee4, and restoring the only file it touches solves the issue, tested by building the latest stable version 1.25.0

[Dryadxon]

I spent a little extra time trying to figure out the underlying cause of the issue, and it seems that removing the following check is enough to fix the problem. https://github.com/OmniSharp/omnisharp-vscode/blob/6c306e8888be4f53423d7f4d253777e53c661ee4/src/features/diagnosticsProvider.ts#L215 Again, tested on the latest stable version.

[Dryadxon]

According to OmniSharp Roslyn the percentage is formatted, but CultureInfo is not provided, could this be the real problem?
Doing a simple test, where I emit the event.ProjectFilePath on a dedicated output channel, I notice that the percentage is formatted without the space, which should not in this case.
Another possibility is that somewhere the space is removed, before sending the event or receiving it, but I couldn't see anything related.

[rjgotten]

... Wow. Now there's a nice example of how/why you shouldn't fudge data-transfer by piggy-backing it into stringified fields. There should just be an additional field in the ProjectDiagnosticStatus event to track progress separate from the ProjectFilePath, e.g.

export interface ProjectDiagnosticStatus {
    Status: DiagnosticStatus;
    ProjectFilePath: string;
    Progress: number;
    Type: "background";
}

And then the BackgroundWorkStatusBarObserver should be what's responsible for ingesting both ProjectFilePath and Progress and creating a decent display representation out of things.

Failing that though... Regex to extract the percentage? (🤮 - I know...)

[Dryadxon]

Perhaps, as a temporary fix anything from the removal of that control, the use of a Regex or simply add another check || event.ProjectFilePath === "(100%)" could do the job, but those are just workarounds to the problem in my opinion.
The event API that is currently being used is considered old and maintained for compatibility with older clients.
Therefore, in my opinion, we should use BackgroundDiagnosticStatusMessage instead of ProjectDiagnosticStatusMessage, which as you can read in the link I sent in my previous comment, is the most recent type of event and allows for more control, such as a better check that cannot be affected by the user's locale: event.NumberFilesRemaining === 0.
But in any case, it's up to @JoeRobich or any other O# maintainer to choose what to do. If I'm wrong don't hesitate to tell me, I looked at this code base only two days ago, and it is possible that I missed something or misunderstood how the protocol works.

[rjgotten]

Therefore, in my opinion, we should use BackgroundDiagnosticStatusMessage instead of ProjectDiagnosticStatusMessage, which as you can read in the link I sent in my previous comment, is the most recent type of event and allows for more control

You know; I honestly complete glanced passed that bit of the forwarder's code before. Fine case of banner blindness.

Yeah; it looks like the new(er) BackgroundDiagnosticStatusMessage would indeed be what's wanted. :+1:

[X9VoiD]

Any news for this issue?

[rjgotten]

@X9VoiD Nada, afaik. Personally, it's holding me back from updating beyond 1.24.1 -- which means I also have to forego some other bugfixes as well as live with some incompatibility problems with up-to-date versions of VSCode, but that is imho still a significantly better experience than having nothing reported to the VSCode Problems list.

You'd think @JoeRobich after previously being addresssed directly, would at the very least have had the time to reply by now on what their take is on this issue. I mean; it's been literally two months of radio silence on an issue that is essentially making every version of the C# extension passed 1.24.1 utterly useless.

[Dryadxon]

Since no feedback was given by an O# developer, I made a pull-request of the fix, which in my opinion, should be applied.
Hoping that this does not irritate anyone, I would have preferred to receive guidance before doing so.