1.25.2 no longer finds Mono installation

[dev-mdean]

Issue Description

Though issues #5443 and #5444 were closed with the release of 1.25.2, it appears that Omnisharp still no longer finds the Mono installation. This previous issues seemed to be focused on Mac OS Ventura 13.0 but older versions of Mac OS, for instance Mac OS Monterey 12.6, are still experiencing it.

Steps to Reproduce

Upgrade the C# extension from 1.25.0 to 1.25.2. Omnisharp fails and dialog appears when opening a C# project or restarting Onmisharp.

Logs

OmniSharp log

OmniSharp failed to start because of missing requirements.

C# log

Empty

Environment information

VSCode version: 1.73.1
C# Extension: 1.25.2

Mono Information

OmniSharp using mono: 6.12.0

Dotnet Information

.NET SDK (reflecting any global.json): Version: 6.0.300 Commit: 8473146e7d

Runtime Environment:
OS Name: Mac OS X
OS Version: 12.6
OS Platform: Darwin
RID: osx.12-x64
Base Path: /usr/local/share/dotnet/sdk/6.0.300/

Host (useful for support):
Version: 6.0.5
Commit: 70ae3df4a6

.NET SDKs installed:
6.0.300 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

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

Visual Studio Code Extensions

Extension	Author	Version
alphabetical-sorter	ue	2.0.1
better-comments	aaron-bond	3.0.2
code-spell-checker	streetsidesoftware	2.11.0
cold-steel	dev-mdean	0.0.6
csharp	ms-dotnettools	1.25.2
git-graph	mhutchie	1.30.0
luna-paint	Tyriar	0.16.0
markdown-all-in-one	yzhang	3.4.3
mustache	dawhite	1.1.1
vscode-counter	uctakeoff	3.1.0
vscode-css-formatter	aeschli	1.0.2
vscode-nuget-package-manager	jmrog	1.1.6

[ericdrobinson]

I am experiencing this as well. I updated my Mono installation (from 6.12.0.122 to 6.12.0.182). It fixed the issue for one local repository. When I opened a second local repository, the error reappeared and requested that I install Mono.

Both repositories are Unity environments.

Edit: I'm running macOS 13 on Apple Silicon. VS Code is at 1.73.1 and is not running in Rosetta.

[filipw]

can you try setting "omnisharp.monoPath": "/Library/Frameworks/Mono.framework/Versions/Current" in VS Code settings and see if it helps?

[JeffreyLeeExient]

macOS 12.6 here, and I just started getting this today with extension 1.25.2. Everything was fine yesterday (but not sure what extension version I was using then)

Setting "omnisharp.monoPath": "/Library/Frameworks/Mono.framework/Versions/Current" doesn't seem to fix it, despite that being the correct path (mono 6.12.0.122)

[ripperdoc]

Can confirm this also happens on 1.25.2 running on MacOS 10.14.6 Mojave, useModernNet is false and monoPath is /Library/Frameworks/Mono.framework/Versions/Current.

[dev-mdean]

@filipw - I also tried setting "omnisharp.monoPath": "/Library/Frameworks/Mono.framework/Versions/Current" and it did not fix the issue.

[Zindswini]

I am also experiencing the issue with 1.25.2, on Fedora 36 in a Unity project. Reverting to 1.25.0 fixes the issue. Setting the path to /usr/lib/mono/ or /usr/bin/mono had no effect.

[filipw]

This error is also emitted when msbuild is missing on the PATH (it is assumed to be incomplete mono installation). Does running msbuild --version produce the correct version output?

[JeffreyLeeExient]

Yes, for me the mono install is on PATH and appears to be functional.

jeffrey@Jeffreys-Mac-mini ~ % echo $PATH      
/Users/jeffrey/.sdkman/candidates/gradle/current/bin:/Users/jeffrey/.nvm/versions/node/v17.6.0/bin:/Users/jeffrey/google-cloud-sdk/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/usr/local/share/dotnet/x64/
jeffrey@Jeffreys-Mac-mini ~ % which msbuild   
/Library/Frameworks/Mono.framework/Versions/Current/Commands/msbuild
jeffrey@Jeffreys-Mac-mini ~ % msbuild -version
Microsoft (R) Build Engine version 16.6.0 for Mono
Copyright (C) Microsoft Corporation. All rights reserved.

16.6.0.10801
jeffrey@Jeffreys-Mac-mini ~ % which mono
/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono
jeffrey@Jeffreys-Mac-mini ~ % mono --version
Mono JIT compiler version 6.12.0.122 (2020-02/c621c35ffa0 Wed Feb 10 00:51:43 EST 2021)
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)

As to whether it's the "correct" version of msbuild, the mono website suggests that mono 6.12 ships with msbuild 16.9, but this issue (and the contents of my machine) suggests that it's actually shipping with 16.6 (but I guess you're already familiar with that problem @filipw since you created that issue)

Also reverting back to 1.25.0 did fix the issue for me.

[dev-mdean]

Running msbuild -version does produce the correct output. I don't have msbuild specifically specified on the PATH but I do have the path to its parent folder, /Library/Frameworks/Mono.framework/Versions/Current/Commands.

matt.dean ~ % msbuild -version
Microsoft (R) Build Engine version 16.6.0 for Mono
Copyright (C) Microsoft Corporation. All rights reserved.

16.6.0.10801%
matt.dean ~ % echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/matt.dean/.dotnet/tools
matt.dean ~ % which msbuild
/Library/Frameworks/Mono.framework/Versions/Current/Commands/msbuild
matt.dean ~ % mono --version
Mono JIT compiler version 6.12.0.122 (2020-02/c621c35ffa0 Wed Feb 10 00:51:43 EST 2021)
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)
matt.dean ~ % which mono
/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono

[dev-mdean]

@filipw - I did try adding the specific location of msbuild to the PATH but that did not fix the issue, it still thinks I have an incomplete version of mono

matt.dean ~ % msbuild -version
Microsoft (R) Build Engine version 16.6.0 for Mono
Copyright (C) Microsoft Corporation. All rights reserved.

16.6.0.10801%
matt.dean ~ % echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/matt.dean/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands/msbuild

[FabienSailliet]

I have the same issue using 1.25.2 on Linux Fedora with Mono installed using the dnf mono-devel package. The msbuild command can be called without any issue from a shell but when loading, the extension gives me the following error:

The extension loads perfectly if I downgrade it to 1.25.1.

[filipw]

Thanks to everyone who posted their output here.

It seems like the common thread is that everyone experiencing this is on Mono 6.12.0.122, which includes msbuild 16.6.0.10801.
The latest stable Mono (https://www.mono-project.com/download/stable/) is 6.12.0.182 which sounds like not much of a difference, but actually includes msbuild 16.10.1.31401.

If you are affected, can you try upgrading your global Mono installation?

[ericdrobinson]

If you are affected, can you try upgrading your global Mono installation?

I did this the first time I ran into the issue. Didn't change anything for me: this issue continues to occur.

[dev-mdean]

@filipw - Upgrading my global Mono installation to the latest stable version 6.12.0.182 looks like it has fixed the issue for me.

[lugehorsam]

I'm still experiencing this dialog popup issue on Ventura on 1.5.2 with Mono JIT compiler version 6.12.0.182 and which mono returning
/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono

[ericdrobinson]

@dev-mdean But does that fixed state persist? Can you please try activating the extension in another VS Code window? And try restarting VS Code to see if the issue resurfaces?

In my experience, upgrading to the latest Mono worked once and then the problem resurfaced.

[dev-mdean]

@ericdrobinson - The fixed state has persisted. Restarting did not cause the issue to resurface and I can have multiple instances active in separate VS Code windows. Our OS versions and processors are different so maybe updating Mono doesn't fix the issue for your configuration?

I am running Mac OS 12.6 with an Intel processor.

[ericdrobinson]

The fixed state has persisted. Restarting did not cause the issue to resurface and I can have multiple instances active in separate VS Code windows.

@dev-mdean Are those multiple instances of VS Code with the same C# project loaded? If so, can you try opening a VS Code window and point it to another C# project?

[dev-mdean]

@ericdrobinson - The multiple instances I loaded were separate C# projects.

[ratbag98]

In my experience, upgrading to the latest Mono worked once and then the problem resurfaced.

My experience as well. Likewise if I uninstall the plugin and reinstall - the system works until I close VSCode. At next restart with a C# project it will bring up the error.

Mac OS 13.0.1 (Intel), msbuild: 16.10.1.31401, mono: 6.12.0.182.

[filipw]

The reason why it works with newer Mono (and newer MsBuild) is that the check is done by executing msbuild --version which is supported in a newer MsBuild, while the older one requires msbuild -version (single dash parameter).

The fact that you experience "a loss" of this at some point is unrelated to the root cause of this issue (which was the incompatible MsBuild).

We execute the MsBuild check by spinning a child process from VS Code, the same as we do for Mono - however, there we also experience similar loss of PATH variables - which seems to me is a VS Code problem - see microsoft/vscode#118460 (there are a few related issues too). Seemingly other tasks, extensions or processes, unrelated to the C# extension can cause a reset of PATH thus breaking these checks that are relying on PATH. Also upon restart, depending on which terminal or UI VS Code is started, may impact the things available on the PATH inside VS Code. We worked around it by adding manual PATH entry for Mono "omnisharp.monoPath" which acts as a fallback in case Mono is not found on the PATH, but it is currently only used for Mono check, not for MsBuild check (which goes directly to PATH). To improve this experience, we should use this Mono PATH for MsBuild version check too.

[ArtyIF]

The issue seems to be this line: https://github.com/OmniSharp/omnisharp-vscode/blob/11758b7b8b525689c193e838aacf5a1e9c05bcf9/src/utils/getMSBuildInfo.ts#L22

The function it's in (getMSBuildVersion) seems to only be called when useModernNet is false, i.e. when Mono is used. The issue is that, as filipw pointed out, Mono's MSBuild uses a single dash, while the extension calls it with a double dash. I removed the extra dashes in a transpiled extension.js file (Ctrl+F FTW), and it works great with a Unity project now. I enabled useModernNet to check if there are any regressions, and everything seems to work fine - at least, it detects my dotnet msbuild install.

Mind you, I only tested it on Linux (Fedora 37) - on other platforms it might be a different story.

[heshuimu]

I still have this issue, but only happens when opening a second C# project. Whatever the first project I open, VS Code will load OmniSharp just fine, but as soon as I open a new project, the warning window comes back. Is this a known issue? If not, I can open a new issue.

[333fred]

We haven't done a release with this fix yet.

[heshuimu]

We haven't done a release with this fix yet.

Yes, I understand. I was just curious if what I saw was a known issue and if this fix will resolve it, since the issue I see only happens if I open a second VS Code window. 🙂

[hellodudu]

@heshuimu
You saved my whole day, bro!