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.

[breadnone]

To those who're having problems with Unity after the upgrade. Delete your csproj files and Re-generate from Unity

[zachstronaut]

To those who're having problems with Unity after the upgrade. Delete your csproj files and Re-generate from Unity

That definitely did not work for me. Downgrading to 1.23.2 fixed the problem immediately, though.

[filipw]

@juniordiscart thanks a lot for providing the repro ZIP. very much appreciated. Unfortunately, I am unable to see any issues with it.

I am using Unity 2019.4.12f1 (same as you used to create this project) and when I open this with the 1.23.4 extension and Mono 6.12 installed, it seems to work fine for all intellisense, including all of the Unity namespaces.

This is bizarre to me, because clearly plenty of people have reported issues and I can't explain that at the moment 😄

if anyone has some suggestions that would be most welcome 😫

[juniordiscart]

@filipw
These are the kind of errors I have all over the place, just opening that project in VSCode. I've also added the omnisharp log, but no warnings or errors are seen. C# and Razor logs also show nothing erroneous.

Mono version:
Mono JIT compiler version 6.12.0.90 (2020-02/d3daacdaa80 Thu Jul 30 16:18:06 EDT 2020)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS:
SIGSEGV: altstack
Notification: kqueue
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: yes(610)
Suspend: hybrid
GC: sgen (concurrent by default)

OmnisharpLog.txt

In a extremely rare case, I do get them to load properly it seems. I've been trying to find some kind of pattern, including what @breadnone suggested, but nothing so far. And reverting back to 1.23.2 immediately fixes it.

[drew-512]

@juniordiscart thanks a lot for providing the repro ZIP. very much appreciated. Unfortunately, I am unable to see any issues with it.

I am using Unity 2019.4.12f1 (same as you used to create this project) and when I open this with the 1.23.4 extension and Mono 6.12 installed, it seems to work fine for all intellisense, including all of the Unity namespaces.

@filipw Thanks for your badass work and attention on this!!

I didn't see this issue appear until I upgraded from 2020.1.8 to 2020.1.10, so maybe try opening the project in 2020.1.10 and see if that does it? Or perhaps it's caused by that? I was also using 1.23.3 when I did that upgrade (and so something in having 1.23.3+2020.1.8 and upgrading to 2020.1.10 exposed it). Reverting to 1.23.2 did the trick, however in that I nuked all my .csproj files and regenerated them from Unity.

[filipw]

@juniordiscart could you try going to ~/.vscode/extensions/ms-dotnettools.csharp-1.23.4/.omnisharp/1.37.3/omnisharp/ (so basically the location of the extension and then omnisharp folder underneath) and replace the OmniSharp.MSBuild.dll with the one attached to my comment? and then restart VS Code and try again

OmniSharp.MSBuild.dll.zip

It is the exact same version as we shipped with Omnisharp 1.37.3 (which is bundled with extension 1.23.4) except it contains a revert of one commit that - if I had to make a bet - is the most likely candidate to be causing this bad behavior here.

Thank you! 🙏

@drew-512 yeah perhaps the fact that I didn't have anything installed related to Unity beforehand is somehow connected to the fact that I can't seem to reproduce it...

[juniordiscart]

@filipw with 1.23.4 installed and the modified DLL it seems to run fine on 2 other projects I experienced the issue. So I think you got a good lead there. :)

OmnisharpLog.txt

[filipw]

oh that's great news! thank you.
This DLL contains a revert of this PR OmniSharp/omnisharp-roslyn#1956
I was suspecting this might be the culprit and it sounds like it really is the case

[JoeRobich]

@juniordiscart Thanks so much for sharing a repro project with us. I was able to reproduce the issue you were seeing. After identifying that types from the ResourceManager namespace were not being resolved, I looked at the ProjectReference for Unity.ResourceManager. What I found was that Unity configured the <ReferenceOutputAssembly> property to false. From a tooling standpoint this is equivalent to the project not being referenced at all.

    <ProjectReference Include="Unity.ResourceManager.csproj">
       <Project>{e59f427f-4e42-aac3-7f03-095fa3624f7d}</Project>
       <Name>Unity.ResourceManager</Name>
!      <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
    </ProjectReference>

This has been an issue for Unity previously as you can see from this issue - https://issuetracker.unity3d.com/issues/referenceoutputassembly-key-is-set-to-false-in-project-references. One of the commenters in the thread suggested 3 days ago to roll back your Unity VSCode package back to 1.1.3 and regenerate project files - "It seems the recommendation at the moment is to actually roll back to 1.1.3. This is (finally) working correctly for my on my machine."

[juniordiscart]

@JoeRobich You're right. That one helps too! Thanks! I think I'll stick with your approach for now to use the previous VS Code Package for Unity. :)

[filipw]

I will just add that in the linked PR (OmniSharp/omnisharp-roslyn#1956) OmniSharp added a bug fix that actually fixed the handling of ReferenceOutputAssembly MSBuild property (for reasons unrelated to Unity). This shipped in extension 1.23.3.

So before 1.23.3, the linked Unity bug related to generating <ReferenceOutputAssembly>false</ReferenceOutputAssembly> was not affecting OmniSharp, due to OmniSharp having its own bug (not handling it). In a twisted way, the bugs canceled each other out.

Once that OmniSharp bug was fixed, the Unity bug became the remaining visible problem though.

[ericdrobinson]

@JoeRobich @filipw I was looking at that PR (OmniSharp/omnisharp-roslyn#1956) this morning with suspicion as well but didn't have time to fully investigate. Glad that you were able to identify the [likely?] source of the issue!

The next logical question is whether or not anyone at Unity is aware of the new incompatibility. The Changelog for v1.2.0 looks to have some suspicious entries:

• Do not reference projects that has not been generated (case 1211057)
• Only open files that exists (case 1188394)
• Add individual toggle buttons for generating csprojects for packages
• Add support for Roslyn analyzers in project generation through csc.rsp and compiled assembly references
• Remove Release build target from csproj and sln

The one I bolded above seems relevant to this issue. The line @JoeRobich pointed out appears to have been added with v1.2.0. Given the contents of Unity's Case 1211057 it seems like the <ReferenceOutputAssembly>false</ReferenceOutputAssembly> line was added to workaround some issues with a change in v1.1.4 that broke things for many people.

Another question this raises is "who is correct?" Is Unity 'correct' when setting ReferenceOutputAssembly to false? Or was the bug introduced in the OmniSharp/omnisharp-roslyn#1956 PR?

UPDATE: @filipw posted while I was writing this. It appears that the Unity change was a workaround for a bug in OmniSharp that was fixed in 1.23.3. At this point it seems that Unity needs to update their VSCode integration package to fix this.

In the meanwhile, the options are:

1. Update OmniSharp to latest; stick with v1.1.3 of Unity's "Visual Studio Code Editor" package.
2. Update "Visual Studio Code Editor" package to latest; stick with OmniSharp v1.23.2.

Given that VSCode likes to update extensions automatically for us, It's probably best to go with option 1 above and update the Unity side once Unity fixes the issue on their end.

[miniwolf]

I am glad this message reached me, it took quite a few jumps. I will immediately remove this workaround and ship a new version of the package as soon as possible.

[sttz]

Can confirm that with removing the ReferenceOutputAssembly, there are no more missing references with the VSCode C# extension v1.23.4.

Steps I took:

• Embed the latest VSCode Unity package (v1.2.2)
• Edit ProjectGeneration.cs and remove ine 479, which adds <ReferenceOutputAssembly>false</ReferenceOutputAssembly>
• Delete all project files in the Unity project and let it regenerate them

[TCROC]

I found a fork of the VS Code UPM that has the fix: https://github.com/legionaryu/com.unity.ide.vscode. I tested it on my end and it seems to be a good substituted until Unity rolls a patch out on their end.

[miniwolf]

The package has been released, so you now can manually update to VSCode package 1.2.3 in Unity through Package Manager.

[ericdrobinson]

you now can manually update to VSCode package 1.2.3 in Unity through Package Manager.

Can confirm that this version addresses the issue. Awesome, thanks!

[JoeRobich]

The package has been released, so you now can manually update to VSCode package 1.2.3 in Unity through Package Manager.

@kalvinpearce Since a new VSCode package is available from Unity that resolves this issue, I will close it now. Thanks @miniwolf !

[filipw]

thanks everyone for your help and patience

[jueane]

I spent almost one day on this problem.It's nice to see the problem has been resolved.

[marcospgp]

Can confirm, deleting all .csproj files and making Unity regenerate them fixed an issue where VSCode wasn't recognizing an import (while that error was not showing up in Unity's console)