OmniSharp regularly "loses" Mono path, only solvable by restart of both VS Code and Unity

[ripperdoc]

Issue Description

OmniSharp regularly "loses" Mono path, only solvable by restart of both VS Code and Unity. The error message is: [ERROR] Error: Unable to find Mono. Update the "omnisharp.monoPath" setting to point to the folder containing Mono's '/bin' folder., but the monoPath is correctly set and mono can be found on that location.

Steps to Reproduce

I cannot reproduce it exactly. It typically appears once every few days during daily usage. I know that VS Code may get different environment depending on where it was launched from, but I would say typically this appears after coming back from Standby or after restarting Unity (VS Code is rarely restarted, it's far more stable than Unity :) ).

Expected Behavior

That it would always find the mono executable.

Actual Behavior

Logs

OmniSharp log

Starting OmniSharp server at 6/8/2022, 9:33:36 AM Target: /Users/martin/dev/src/fictive/fictive-unity-new/fictive-unity-new.sln [ERROR] Error: Unable to find Mono. Update the "omnisharp.monoPath" setting to point to the folder containing Mono's '/bin' folder.

C# log

(empty)

Environment information

Current monopath setting: "omnisharp.monoPath": "/Library/Frameworks/Mono.framework/Versions/Current/bin/"

PATH as seen from VS Code terminal: PATH=/Users/martin/.pyenv/shims:/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin:/Library/Frameworks/Mono.framework/Versions/Current/bin:/Users/martin/Library/Android/sdk/emulator:/Users/martin/Library/Android/sdk/tools:/Users/martin/Library/Android/sdk/platform-tools:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands

VSCode version: 1.67.2 C# Extension: 1.25.0

Mono Information

There is a problem with running OmniSharp on mono: Error: Unable to find Mono. Update the "omnisharp.monoPath" setting to point to the folder containing Mono's '/bin' folder.

Dotnet Information

A valid dotnet installation could not be found.

Visual Studio Code Extensions

|Extension|Author|Version| |---|---|---| |autodocstring|njpwerner|0.6.1| |AWK|luggage66|0.0.2| |better-toml|bungcip|0.3.2| |csharp|ms-dotnettools|1.25.0| |foam-vscode|foam|0.18.4| |gitlens|eamodio|12.0.7| |hexeditor|ms-vscode|1.9.6| |jinjahtml|samuelcolvin|0.17.0| |jupyter|ms-toolsai|2022.4.1021342353| |jupyter-keymap|ms-toolsai|1.0.0| |jupyter-renderers|ms-toolsai|1.0.8| |live-server|ms-vscode|0.2.12| |markdown-all-in-one|yzhang|3.4.3| |markdown-link-expander|skn0tt|0.2.1| |markdown-links|tchayen|0.8.0| |nodejs-repl|lostfields|0.5.15| |php-debug|xdebug|1.26.1| |php-intellisense|felixfbecker|2.3.14| |prettier-vscode|esbenp|9.5.0| |python|ms-python|2022.6.3| |rainbow-csv|mechatroner|2.4.0| |rewrap|stkb|1.16.3| |shellcheck|timonwong|0.19.4| |test-adapter-converter|ms-vscode|0.1.6| |theme-bright-day|Squarelogic|0.1.7| |theme-gray-matter|philipbe|1.7.0| |unity-debug|deitry|3.0.11| |view-in-browser|qinjia|0.0.5| |vscode-counter|uctakeoff|3.0.5| |vscode-coverage-gutters|ryanluker|2.10.1| |vscode-docker|ms-azuretools|1.22.0| |vscode-edit-csv|janisdd|0.6.10| |vscode-eslint|dbaeumer|2.2.2| |vscode-front-matter|eliostruyf|7.3.2| |vscode-gutter-preview|kisstkondoros|0.30.0| |vscode-markdown-notes|kortina|0.0.24| |vscode-mocha-test-adapter|hbenl|2.13.5| |vscode-nginx-conf-hint|hangxingliu|0.3.0| |vscode-pull-request-github|GitHub|0.42.0| |vscode-pylance|ms-python|2022.6.0| |vscode-styled-components|jpoissonnier|1.7.0| |vscode-svgviewer|cssho|2.0.0| |vscode-test-explorer|hbenl|2.21.1|;

[conlanpatrek]

+1 with this.

This is especially problematic if you still have the default settings that come with the extension (no explicit "monoPath" and "useGlobalMono" set to "auto"), as it will automatically switch to the version of Mono that comes bundled with OmniSharp when it fails to locate global mono, making debugging this even more confusing.

(Thanks for the "Restart VSCode" advice btw. I had restarted the extension several times, but it wasn't until I restarted VSCode that the extension started functioning correctly)

[Mister-CK]

+1, new to unity/C#. Took me a few hours to get it to work last night. VSC could find nothing by itself I had to set all the paths by hand. Took me hours to finally get it to work. Today I had the same problem again, I think because I only got it to work for the workspace last night. And today I am working on a new project.

Restarting helped! But this should just be working without hours of configuring, especially when you're new to a field.

[jqhan]

+1 with version 1.25.0 of the C# extension. The only thing that solves it seems indeed to be restarting VSCode.

[Mister-CK]

@jqhan, What worked for me was to use Visual Studio for Mac, instead of normal Visual Studio Code. that one didn't have any issues.

[jqhan]

@Mister-CK thanks for sharing, good tip! I gave it a go, I stopped using VS Code and tried Visual Studio instead, v. 8.10.25. I haven't run into any OmniSharp issues yet.

[gregharding]

On Mac, I just updated from Omnisharp 1.25.0 to 1.25.1 and as usual Omnisharp completely falls over after an update. Usually it's a matter of updating a few paths or restarting, but this time it's suggesting a total reinstallation of Mono in a modal popup. I already have the latest Mono installed and have been juggling the extension settings for useModernNet, Mono Path and other settings for the last few years of versions to keep VS Code + Omnisharp working happily with Unity projects.

I haven't figured out how to make 1.25.1 work so rolling back to 1.25.0 and waiting for it all to blow over again.

Update: And very handily today 1.25.2 is out which fixes everything up again. Thanks!

[jjmontesl]

Today I had to revert to 1.25.1 as 1.25.2 failed to detect requirements, suggesting me to download mono (Ubuntu 20.04, with useModernNet=false).