OmniSharp not working with legacy .NET projects on Fedora 36 #5232
Comments
|
Full framework development now requires you to set You will also need a complete system install of Mono and MSBuild. Please try the |
No, it doesn't resolve the issue. The only dependencies |
|
Thanks for checking on that package. I will not pretend I know anything about how these Fedora packages are maintained. Doing a search for a MSBuild package isn't turning up anything for Fedora (https://pkgs.org/search/?q=msbuild). I will keep investigating. |
|
Looks like there is a closed issue for an installable Mono MSBuild package for Fedora - mono/linux-packaging-msbuild#18. If only there were an equivalent to one of these packages - https://archlinux.pkgs.org/rolling/archlinux-community-x86_64/mono-msbuild-16.10.1.xamarinxplat.2021.05.26.14.00-2-x86_64.pkg.tar.zst.html & https://voidlinux.pkgs.org/current/voidlinux-main-x86_64/msbuild-bin-16.6_2.x86_64.xbps.html |
|
Posting this here from #5120 As far as I can tell msbuild is installed properly on my system (Fedora 36). I have Not sure why Omnisharp can't find it... I got it to work by downgrading the extension to 1.24.4, and adding the following to the settings.json: From here upgrading to 1.25.0 breaks the MSBuild connection again. Seems 1.25.0 is the problem? |
|
@esklarski Mono does not use the dotnet SDK MSBuild. You would need to check What Fedora seems to be lacking is a mono-msbuild package similar to https://archlinux.pkgs.org/rolling/archlinux-community-x86_64/mono-msbuild-16.10.1.xamarinxplat.2021.05.26.14.00-2-x86_64.pkg.tar.zst.html which installs the Mono MSBuild. According to this post (https://blog.timpack.org/fedora-29-and-mono-5) there used to be a msbuild package. |
|
Perhaps these instructions to install the Fedora mono packages would resolve the issue https://www.mono-project.com/download/stable/#download-lin-fedora |
|
"omnisharp.useModernNet": false, only set this one will take effect at 1.25.0, and delete others - "omnisharp.path": "", |
Okay, that answers that.
|
I tried this but there were dependancy conflicts and I know nothing about resolving those. I'll be looking into this, but I will also try talking to a Fedora person about the dotnet package. |
|
So I don't think the mono-project thing is going to work... ¯_(ツ)_/¯ |
|
Downgrading to 1.24.x or earlier works as a workaround for now, but is obviously undesired |
|
@esklarski On a fresh Fedora 36 install I ran the following successfully. Then checked the msbuild version See terminal output.See OmniSharp Log. |
|
Yeah, talking with someone on the DotNetEvolution Discord I found the same thing. On a fresh install the instructions work. But this was easily solved. Running So it would seem Fedora users need to ensure no mono packages are installed before proceeding with the Mono Project package install. I'll be testing the v1.25 extension again this evening and will report back. |
|
Okay, I can confirm everything seems to be working properly now. Thanks for the help. Fedora users beware of orphaned mono packages ;-) |
|
Glad things are working now. Will close this out. |
|
This worked for me:
These steps basically. Although I had to But now I'm getting the following error. It seems that the version of mono on my fedora 35 installation does not have the required version of |
|
@ccaneke If your projects are not .NET SDK projects, then you can ignore that warning. Otherwise, you would want to set |
|
@ccaneke @esklarski @JoeRobich After following those steps, I noticed that I only had |
|
@BagelSeasoning234 I believe the latest MSBuild that is shipping with the release Mono is 16.10 (ultimately it depends on your distro). The .NET SDK ships with the latest 17.x MSBuild, however that may not help since last I recall Unity generates Full Framework projects not SDK projects. |
|
@BagelSeasoning234 After doing some snooping, it appears that maybe a community member has written a plugin that will generate SDK style projects for Unity. You could then run with |
|
Alright, thanks! It appears as though the immediate issue I was having with the vim plugin was caused by another problem that I was able to resolve, but given that I still get warning messages about updating |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue Description
OmniSharp has recently stopped shipping Mono with its installs. While on most Linux distros this causes no issues, on Fedora 36 this breaks non-SDK-style projects like Unity projects, since Fedora 36 does not ship Mono MSBuild anywhere in its repositories, which is required by OmniSharp for non-SDK-style projects.
Steps to Reproduce
Expected Behavior
OmniSharp boots up and works as intended.
Actual Behavior
OmniSharp boots up, but reports that no MSBuild has been found.
Logs
OmniSharp log
OmniSharp server started with Mono 6.12.0.
Path: /home/artyif/.vscode/extensions/ms-dotnettools.csharp-1.25.0-linux-x64/.omnisharp/1.39.0/omnisharp/OmniSharp.exe
PID: 109682
Starting OmniSharp on fedora 36.0 (x64)
info: OmniSharp.Services.DotNetCliService
Checking the 'DOTNET_ROOT' environment variable to find a .NET SDK
info: OmniSharp.Services.DotNetCliService
DotNetPath set to /usr/lib64/dotnet/dotnet
info: OmniSharp.MSBuild.Discovery.MSBuildLocator
Located 0 MSBuild instance(s)
Could not locate MSBuild instance to register with OmniSharp.
Environment information
VSCode version: 1.66.2
C# Extension: 1.25.0
Mono Information
OmniSharp using mono :6.12.0Dotnet Information
.NET SDK (reflecting any global.json): Version: 6.0.105 Commit: 1c35735293Runtime Environment:
OS Name: fedora
OS Version: 36
OS Platform: Linux
RID: fedora.36-x64
Base Path: /usr/lib64/dotnet/sdk/6.0.105/
Host (useful for support):
Version: 6.0.5
Commit: 70ae3df4a6
.NET SDKs installed:
6.0.105 [/usr/lib64/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.5 [/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.5 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download
Visual Studio Code Extensions
The text was updated successfully, but these errors were encountered: