Issues when upgrading to 1.23.3 - Unity assembly definitions not found correctly

[kalvinpearce]

Issue Description

So been scratching my head on this one for a day now but since updating to version 1.23.3, any assembly definitions I have created from within Unity, seem to not get discovered correctly from within VS code. Any class from other assemblies was not available and would produce errors like CS1061. My assembly defs are correctly set up and were definitely working on version 1.23.2 (this is confirmed by rolling back to this version). I am not sure if this is an omnisharp issue completely but there is no errors within Unity so I assume so.

Steps to Reproduce

Install 1.23.3, set up 2 assemblies within Unity and link them. From within the one of the assembly's classes, try to reference something from the other assembly and it will produce errors.

Expected Behavior

Should find the assemblies correctly

Actual Behavior

Produces errors saying it cannot find the namespace/class/function etc.

Environment information

VSCode version: 1.50.0
C# Extension: 1.23.2

Dotnet Information

.NET Core SDK (reflecting any global.json): Version: 3.1.402 Commit: 9b5de826fd

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

Host (useful for support):
Version: 3.1.8
Commit: 9c1330dedd

.NET Core SDKs installed:
3.0.100 [C:\Program Files\dotnet\sdk]
3.1.402 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

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

Visual Studio Code Extensions

Extension	Author	Version
awesome-flutter-snippets	Nash	2.0.4
bracket-pair-colorizer-2	CoenraadS	0.2.0
code-spell-checker	streetsidesoftware	1.9.2
csharp	ms-dotnettools	1.23.2
dart-code	Dart-Code	3.15.0
docomment	k--kato	0.1.18
EditorConfig	EditorConfig	0.15.1
electron	kuscamara	0.2.5
errorlens	usernamehw	3.2.3
flutter	Dart-Code	3.15.0
git-graph	mhutchie	1.26.0
gitlens	eamodio	10.2.2
pubspec-assist	jeroen-meijer	2.2.1
shader	slevesque	1.1.4
shaderlabvscodefree	amlovey	1.2.0
TabOut	albert	0.2.0
theme-bluloco-dark	uloco	3.2.0
vscode-dashboard	kruemelkatze	2.2.2
vscode-gitignore-generator	piotrpalarz	1.0.2
vscode-theme-onedark	akamud	2.2.2
vscode-theme-superonedark	seansassenrath	0.0.15
vscode-typescript-next	ms-vscode	4.1.20201013
vscode-yaml	redhat	0.11.1
vsfire	toba	1.4.1

[kalvinpearce]

A temporary work-around to anyone who finds this for now:

• Right-click the C# extention from within VS Code or click the little cog/settings icon on the C# extention in the extentions list
• Select Install Another Version...
• Wait for the list of versions to popup and select version 1.23.2

[breadnone]

Now my work setup isn't as comfortable as before this error occurs. I had to filter the assembly errors on active documents but this definitely not a solution at all as I can't trace what might wrong on other related files.
The solution above could not fix the error on my end, reinstalling previous version and regenerating project files also didn't help. I've lost words for this, sorry for having to say this, but every update is a nightmare.

With the amount of users using your package, it would be wise to fully test it before release.

EDIT: To those who already done the solution above and still can't get it to work. Remove "latest" from your "omnisharp.path".

[hermitcat]

@kalvinpearce Thank you. I didn't know how to downgrade C# extension.

[EliCDavis]

@breadnone the solution didn't work for me till I did a full restart of VSCode. That might help you.

[wallstudio]

I am avoiding by this.
(ReferenceOutputAssemby=true)
https://github.com/wallstudio/com.unity.ide.vscode

[andymads]

Intellisense was mostly working for me but I was getting a lot of red. Upgrading to the 1.23.4 pre-release didn't help, but downgrading to 1.23.2 has appeared to fix it.

[rhys-vdw]

Can confirm that upgrading to 1.23.4 release did not fix this issue. Downgrading to 1.23.2 did fix my issue.

FYI for me the missing types are anything coming from Unity asmdef files within my Assets/ folder.

[zachstronaut]

My setup was working normally, but then out of the blue the C# extension version 1.23.3 suddenly could not do Intellisense correctly for my project anymore. I didn't change Unity versions. I didn't change C# extension versions. It is possible that Unity rebuilt csproj and/or sln files. The other recent change was upgrading VS Code itself to 1.50.1

I tried upgrading c# to 1.23.4 and that did not help. Downgraded to 1.23.2 and it works again perfectly.

I wonder if the Unity team and this team have a productive open communication channel with each other, because this issue just keeps happening over and over.

[CrowbarSka]

Same issue here. Appeared to be affecting custom packages in Unity that I was loading via Package Manager from my hard disk. I would get that same error that it couldn't find the namespace/definition of anything in my packages, but the project itself worked fine.

Downgrading to C# extension v1.23.2 worked. Using latest VS Code and latest Unity.

[filipw]

I am sorry that you are running into this issue. could you share a project that reproduces it?

[zachstronaut]

There's third party licensed code I can't share, so I'd have to weed the project down to something I can legally share and see if the issue still occurs. Might take me some time, unfortunately.

[rhys-vdw]

@filipw it's a big project and all the csproj files are managed by Unity. What do you need for a minimal reproduction? I'm thinking I can just delete files until there's just one csproj w/ a single file referencing another (with error). Even then you'll likely need Unity and to install the project's UPM packages.

[juniordiscart]

@filipw I've added a minimal project in which I wanted to start this morning but ran into the issue.
When opening the project through Unity (Edit -> Open C# project), open the BuildScriptPackedMode script for example. It will show you a bunch of unrecognized namespaces. This is a fresh project containing none of my actual code, but a package downloaded from the Unity package manager for which I wanted to write some extensions.

AddressablesExtensions.zip

EDIT: I re-uploaded the project as it was meant to be opened in Unity which would then resolve some package dependencies and download them. I've included the packages in the archive.

[zachstronaut]

@filipw I've added a minimal project in which I wanted to start this morning but ran into the issue.
When opening the project through Unity (Edit -> Open C# project), open the BuildScriptPackedMode script for example. It will show you a bunch of unrecognized namespaces. This is a fresh project containing none of my actual code, but a package downloaded from the Unity package manager for which I wanted to write some extensions.

AddressablesExtensions.zip

Does your zip have the csproj and sln files already generated? If you include those @filipw should just be able to open that in VSCode and probably will see the same failures? (Without needing to install Unity, I mean.)

[juniordiscart]

@zachstronaut They are included, both .csproj and .sln. I included the project anyway (pretty barebones, so why not) and happens consistently through that way. It's my primary way of opening the project, so it might be a good use case if it isn't reproducible directly opening the .sln for some reason.