Intellisense out of sync

[bradwilson]

Issue Description

I frequently get a situation where Intellisense is out of sync, even though builds are successful. Restarting Omnisharp usually resolve this, though sometimes restarting VS Code is required.

Steps to Reproduce

Unknown at this time.

Performing package restore (dotnet restore) and/or building (dotnet build) does not resolve the issue, regardless of where they're done from (Code task, Code internal terminal, external terminal, etc.).

Expected Behavior

Intellisense matches known type information.

Actual Behavior

Intellisense shows unexpected errors with type information:

Logs

OmniSharp log

Starting OmniSharp server at 3/20/2019, 10:31:31 AM
    Target: /home/brad/src/appcenter/appcenter/samples/netcore-api/NetCoreApi.sln

OmniSharp server started with Mono 5.18.1.
    Path: /home/brad/.vscode/extensions/ms-vscode.csharp-1.17.1/.omnisharp/1.32.8/omnisharp/OmniSharp.exe
    PID: 12109

[warn]: OmniSharp.MSBuild.ProjectManager
        Unable to resolve assembly '/home/brad/src/appcenter/appcenter/samples/netcore-api/src/bin/Debug/netcoreapp2.2/NetCoreApi.dll'

C# log

This log is empty.

Environment information

VSCode version: 1.32.3
C# Extension: 1.17.1

Mono Information

OmniSharp using global mono :5.18.1

Dotnet Information

.NET Core SDK (reflecting any global.json): Version: 2.2.105 Commit: 7cecb35b92

Runtime Environment:
OS Name: ubuntu
OS Version: 18.10
OS Platform: Linux
RID: ubuntu.18.10-x64
Base Path: /usr/share/dotnet/sdk/2.2.105/

Host (useful for support):
Version: 2.2.3
Commit: 6b8ad509b6

.NET Core SDKs installed:
2.2.105 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.2.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

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

Visual Studio Code Extensions

Extension	Author	Version
azure-pipelines	ms-azure-devops	1.147.2
chat	karigari	0.12.0
code-settings-sync	Shan	3.2.7
code-spell-checker	streetsidesoftware	1.6.10
csharp	ms-vscode	1.17.1
dotnet-test-explorer	formulahendry	0.6.5
EditorConfig	EditorConfig	0.13.0
github-plus-theme	thenikso	1.2.0
gitlens	eamodio	9.5.1
ilspy-vscode	icsharpcode	0.7.5
material-icon-theme	PKief	3.6.3
PowerShell	ms-vscode	1.11.0
quokka-vscode	WallabyJs	1.0.196
ruby	rebornix	0.22.3
toggle-excluded-files	eamodio	1.6.0
vscode-browser-preview	auchenberg	0.4.0
vscode-docker	PeterJausovec	0.6.1
vscode-kubernetes-tools	ms-kubernetes-tools	0.1.18
vscode-typescript-tslint-plugin	ms-vscode	1.0.0
vscode-versionlens	pflannery	0.22.0
vscode-yaml	redhat	0.3.0
vscodeintellicode	VisualStudioExptTeam	1.1.4
vsliveshare	ms-vsliveshare	0.3.1326
vsliveshare-audio	ms-vsliveshare	0.1.48
vsliveshare-pack	ms-vsliveshare	0.2.10

[bradwilson]

BTW, there is nothing particularly special about this project. It's just a .NET Core 2.2 API project sample (it includes several services that we wire up by default for AKS, so it's suitable as a copy/paste for a starter project). If a Microsoft employee wants to look at the code, I can provide a link to an AzDO repository; just reach out to me internally at brwilso@.

[jamars]

@bradwilson, that's probably due to a problem with the Omnisharp server... It's annoying, but if you go to the "Command Palette" (Ctrl-Shift-P) and restart Omnisharp you should have intellisense back to making sense again... ;)

[bradwilson]

Yeah, that's why I reported this bug, because on average I'm restarting Omnisharp upwards of 20x per day (and it's a common complaint on my team).

[robertmiles3]

I have the same issue multiple times per day. I usually "Reload Window" to get it back in shape, but it's super annoying and time draining.

[ielcoro]

I experienced the same issues every day, some scenarios I have seen it include:

• Renaming a code file and then renaming his class name in the same workspace, sometimes it shows duplicated intellisense (both the old class name is available along the new one), or the new class name cannot be resolved.

• Changing a namespace name with Search and Replace, intellisense does not get updated with the new namespace.

• Performing changes in another workspace in the same window or another VS Code window with a project that is a dependency of the current workspace most of the time intellisense does not catch up with the changes.

All of them get resolved via restarting Omnisharp, but it gets annoying, is time consuming, and it explodes when the number of workspaces and projects grows up.

[jmihalich]

Same issue here. VS Code 1.41.1, OmniSharp looks like version 6.2.9200.0. Switching projects via the project selector fixes it too (if you have more than one project in the workspace).

Lately it's been happening to me multiple times per hour.

[stewartadam]

Same issue here, very annoying. I've resorted to building on the command line a lot since IntelliSense is useless without constant restarts.

[Anderson0xFF]

I'm experiencing the same problem, with each change I have to keep restarting.

[ManfredLange]

It seems to be even worse, when you use Remote-Containers with the container running all the time. Omnisharp claims that it cannot load projects while running dotnet build completes without problems.

It's very annoying having to restart Omnisharp server so frequently.

My environment:

• Windows 10
• Docker Desktop 2.4.0.0
• VS Code 1.50.1
• VS Code Extension "C#" (ms-dotnettools.csharp) v1.23.4

A very simple example to reproduce the problem seems to be: create a new file and add a new class. Omnisharp doesn't pick it up.

[JoeRobich]

@ManfredLange @Tekadon58 Could you share the OmniSharp log from the Output pane from a run where you experience this issue?

[ManfredLange]

@JoeRobich As requested here the log file of such an instance. This time I can reproduce that when creating a new file - LanguageEntity.cs in this instance - and then add the code for the new class, i.e. namespace, then class etc, then Omnisharp stops working, i.e. no squigglies under Guid even if using System; is absent.

The log contains a few exceptions. Perhaps these provide a clue of what is happening.

Just for the record, my environment has changed and is now:

• Windows 10.0.18363
• Docker Desktop 2.4.0.0
• Changed: VS Code 1.51.0
• Changed: VS Code Extension "C#": (ms-dotnettools.csharp) v1.23.5

omnisharp-2020-11-07.txt

[ManfredLange]

Here is another Omnisharp log file iwht what looks like errors, e.g. "InvalidOperationException". Happy to send more when I observe similar issues or when I find what looks like errors in the omnisharp output in VS Code. Also, if there are any settings or short experiments that may help with diagnosing this issue, please let me know.

omnisharp-2020-11-08-01.txt

[ManfredLange]

Here is another instance, showing that the adornments (or whatever they are called) are missing in the source code. This happened after a fresh start of the container and a restart of Omnisharp. Then I ran a test under the debugger. The code under test threw an execption as it doesn't meet the test's requirement yet. Nothing out of the ordinary.

Attached the screenshot of the test and the Omnisharp output that goes with it. Interestingly, in this case the omnisharp doesn't appear to show anything of interest. I assume the "adornments" are created by Omnisharp.

I've attached a second screenshot that shows "adornments', e.g. "0 references", but at least 3 of them are in the wrong location, almost randomly.

What else can I do to help diagnosing this? This issue is extremely disruptive. I need to restart omnisharp every couple of minutes. It is a huge impediment to flow.

omnisharp-2020-11-08-02.txt

[scgbear]

Internal Tracking

devdivcsef 412378

[stijnherreman]

I'm seeing this with a file that is modified by an external process, while running the Remote - Containers extension and the opened folder located on my C drive.

.config\dotnet-tools.json

{
	"version": 1,
	"isRoot": true,
	"tools": {
		"nswag.consolecore": {
			"version": "13.10.8",
			"commands": [
				"nswag"
			]
		}
	}
}

.devcontainer\devcontainer.json

{
	"name": "dotnet/sdk:5.0",
	"build": {
		"dockerfile": "Dockerfile",
	},

	"settings": {
		"terminal.integrated.shell.linux": "/bin/bash"
	},

	"extensions": [
		"editorconfig.editorconfig",
		"ms-dotnettools.csharp",
		"tintoy.msbuild-project-tools"
	]
}

.devcontainer\Dockerfile

FROM mcr.microsoft.com/dotnet/sdk:5.0

src\api contains an ASP.NET Core 5 Web API project.
src\importer contains a .NET 5 executable and the following NSwag configuration file:

{
	"runtime": "Net50",
	"documentGenerator": {
		"fromDocument": {
			"url": "http://localhost:5000/swagger/v1/swagger.json"
		}
	},
	"codeGenerators": {
		"openApiToCSharpClient": {
			"className": "ApiClient",
			"operationGenerationMode": "SingleClientFromOperationId",
			"namespace": "Sentury",
			"output": "ApiClient.cs"
		}
	}
}

When ApiClient.cs is modified by running src/importer# dotnet nswag run ApiClient.nswag.json, OmniSharp is unaware of changes to the file. I can manually rename a property in the generated file, restart VS Code, then run the generation command again, and OmniSharp will not be aware of the change by the external tool.

Screenshots from Program.cs:

Log output when hovering the renamed property in ApiClient.cs:

[warn]: OmniSharp.Stdio.Host
        ************ Request ************
{
  "Type": "request",
  "Seq": 705,
  "Command": "/findusages",
  "Arguments": {
    "FileName": "/workspaces/sentury/src/importer/ApiClient.cs",
    "Line": 316,
    "Column": 23,
    "OnlyThisFile": true,
    "ExcludeDefinition": false
  }
}
[fail]: OmniSharp.Stdio.Host
        ************  Response ************ 
{
  "Request_seq": 705,
  "Command": "/findusages",
  "Running": true,
  "Success": false,
  "Message": "\"System.InvalidOperationException: Unexpected null\\n  at Roslyn.Utilities.Contract.Fail (System.String message) [0x00000] in <1b72cf009970430282a46c2931a92a23>:0 \\n  at Microsoft.CodeAnalysis.FindSymbols.FindReferencesSearchEngine.MapToAppropriateSymbol (Microsoft.CodeAnalysis.ISymbol symbol) [0x0003a] in <1b72cf009970430282a46c2931a92a23>:0 \\n  at Microsoft.CodeAnalysis.FindSymbols.FindReferencesSearchEngine.DetermineAllSymbolsCoreAsync (Microsoft.CodeAnalysis.ISymbol symbol, Roslyn.Utilities.ConcurrentSet`1[T] result) [0x0005b] in <1b72cf009970430282a46c2931a92a23>:0 \\n  at Microsoft.CodeAnalysis.FindSymbols.FindReferencesSearchEngine.DetermineAllSymbolsAsync (Microsoft.CodeAnalysis.ISymbol symbol) [0x0009f] in <1b72cf009970430282a46c2931a92a23>:0 \\n  at Microsoft.CodeAnalysis.FindSymbols.FindReferencesSearchEngine.FindReferencesAsync (Microsoft.CodeAnalysis.ISymbol symbol) [0x001d5] in <1b72cf009970430282a46c2931a92a23>:0 \\n  at Microsoft.CodeAnalysis.FindSymbols.FindReferencesSearchEngine.FindReferencesAsync (Microsoft.CodeAnalysis.ISymbol symbol) [0x003ba] in <1b72cf009970430282a46c2931a92a23>:0 \\n  at Microsoft.CodeAnalysis.FindSymbols.FindReferencesSearchEngine.FindReferencesAsync (Microsoft.CodeAnalysis.ISymbol symbol) [0x00463] in <1b72cf009970430282a46c2931a92a23>:0 \\n  at Microsoft.CodeAnalysis.FindSymbols.SymbolFinder.FindReferencesAsync (Microsoft.CodeAnalysis.ISymbol symbol, Microsoft.CodeAnalysis.Solution solution, Microsoft.CodeAnalysis.FindSymbols.IStreamingFindReferencesProgress progress, System.Collections.Immutable.IImmutableSet`1[T] documents, Microsoft.CodeAnalysis.FindSymbols.FindReferencesSearchOptions options, System.Threading.CancellationToken cancellationToken) [0x00267] in <1b72cf009970430282a46c2931a92a23>:0 \\n  at Microsoft.CodeAnalysis.FindSymbols.SymbolFinder.FindReferencesAsync (Microsoft.CodeAnalysis.ISymbol symbol, Microsoft.CodeAnalysis.Solution solution, Microsoft.CodeAnalysis.FindSymbols.IFindReferencesProgress progress, System.Collections.Immutable.IImmutableSet`1[T] documents, Microsoft.CodeAnalysis.FindSymbols.FindReferencesSearchOptions options, System.Threading.CancellationToken cancellationToken) [0x000b3] in <1b72cf009970430282a46c2931a92a23>:0 \\n  at Microsoft.CodeAnalysis.FindSymbols.SymbolFinder.FindReferencesAsync (Microsoft.CodeAnalysis.ISymbol symbol, Microsoft.CodeAnalysis.Solution solution, Microsoft.CodeAnalysis.FindSymbols.IFindReferencesProgress progress, System.Collections.Immutable.IImmutableSet`1[T] documents, System.Threading.CancellationToken cancellationToken) [0x00086] in <1b72cf009970430282a46c2931a92a23>:0 \\n  at OmniSharp.Roslyn.CSharp.Services.Navigation.FindUsagesService.Handle (OmniSharp.Models.FindUsages.FindUsagesRequest request) [0x00390] in <09370a9acd194e4ab6aa0320066dbeaa>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].AggregateResponsesFromLanguageHandlers (OmniSharp.Endpoint.Exports.ExportHandler`2[TRequest,TResponse][] handlers, TRequest request) [0x000a9] in <c13615cca0c74ceaa15dfd4227fc93cf>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].HandleRequestForLanguage (System.String language, TRequest request, OmniSharp.Protocol.RequestPacket packet) [0x000fb] in <c13615cca0c74ceaa15dfd4227fc93cf>:0 \\n  at OmniSharp.Endpoint.EndpointHandler`2[TRequest,TResponse].Process (OmniSharp.Protocol.RequestPacket packet, OmniSharp.Endpoint.LanguageModel model, Newtonsoft.Json.Linq.JToken requestObject) [0x0024b] in <c13615cca0c74ceaa15dfd4227fc93cf>:0 \\n  at OmniSharp.Stdio.Host.HandleRequest (System.String json, Microsoft.Extensions.Logging.ILogger logger) [0x000e8] in <f4f40b9ed3034a528e91f200ff10538e>:0 \"",
  "Body": null,
  "Seq": 804,
  "Type": "response"
}

Manually saving ApiClient.cs in VS Code has no effect. I have to close and reopen the Remote Connection to make everything work again.

[keithallenjackson]

I run into this multiple times a day and I'm a bit surprised this hasn't been a priority to address.

[MSqrl]

Same issue experienced frequently, daily.

[codingatmorning]

Exact same issue I think omnisharp forgets to update, or something maybe it's not polling changes. Especially with libraries that use source generators, after I update an attribute I have to restart omnisharp.

[microhobby]

Still occurring in 2024

[mikadumont]

We've made lots of updates to the C# extension since this issue was filed. @microhobby can you file a new issue if you're still experiencing this with updated logs?