Is it possible to have omnisharp-roslyn target .NET Core?

[Legogris]

Is it possible to use the C# vscode extension without mono at all? On nixos the mono package in repos rarely gets updated and it's a pain to have the extension broken with every other update. I'd wager most users of this extension have 0 use for mono.

[filipw]

yes OmniSharp ships with its own bundled Mono runtime so global Mono installation is not required

[Legogris]

yes OmniSharp ships with its own bundled Mono runtime so global Mono installation is not required

Omnisharps bundled mono runtime does not work on NixOS (this is an inherent thing that can not be worked around). Guix, other architectures and various other setups will also run Core fine but can't run mono.I am asking about running core without mono. This means that users on such systems will have to rebuild mono from source (if even supported at all) if they want to have C# navigation in vscode.

[filipw]

oh I thought the question was if global Mono was mandatory.

If by "Core" you mean ".NET Core" then the answer is currently no, OmniSharp is by design built on top of Mono to provide better/full coverage of the wide variety of MSBuild tasks and projects (.NET Core, Unity, desktop .NET and so on). This would not be possible if it was a .NET Core application since it wouldn't be able to i.e. run arbitrary code that could be part of MSBuild tasks. In fact, it was a .NET Core application at some point in the past but we moved away from it.

For NixOS I know that some people used to do some unofficial stuff like building Mono specifically there to work around the fact the original would be built on a differently configured system etc. There was also this package but it's out of date too https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/omnisharp-roslyn/default.nix I can't help here much since we really currently support OmniSharp on GuixSD/Nix like systems.

[Legogris]

Ah, it sounds kind of weird to me that you wouldn't be able to do any of those things from .NET Core (you can still have the entrypoint in .NET Core and run other binaries for .NET Framework when required, no?), but I guess that's just blissful ignorance on my side!

Take this as a feature request to drop the mono requirement, then I guess!

[filipw]

I will move this to omnisharp-roslyn repo.

[filipw]

We can keep this open but it's not possible to achieve unless we drop support for Unity/desktop .NET which I don't think will happen anytime soon 😃
You can find more information here #988 and here #666 and here #915

[xsoheilalizadeh]

Seems it'll be possible when .NET 5 released, am I right?

[rickardp]

Also consider Alpine linux which is very common these days and not glibc-based. Would not not be possible to use multi targeting (or add the mono stuff as a soft dependency and fail gracefully for mono e.g Xamarin projects) and support a reduced feature set (.NET core projects only) with only .net core installed. The only cases of needing anything beyond that I know of is Unity and Xamarin (IIRC, desktop is now supported on .net core), and there is a ton of projects out there not needing those.

I understand that supporting multiple targets adds complexity, but I think the case of using Alpine-based containers in VS Code devcontainer.json is (or will be) quite common.

[filipw]

Seems it'll be possible when .NET 5 released, am I right?

no there are still issues in terms of executing msbuild tasks that are desktop .NET
additionally, there is currently a dependency on Visual Studio Test Protocol to run and debug tests which is also desktop .NET

[rickardp]

@filipw IMHO the project would benefit greatly from a clear strategy for developing .NET core web/backend services using OmniSharp. Depending on Mono severely restricts the set of containers that can be used.
It is so close to being possible to use VS Code with dev containers for all C# development now and finally ditch Visual Studio. With GitHub code spaces etc coming up, finally getting rid of the Windows VM just to have Visual Studio would be a huge win for the C# developer community. For example, I now do all my Python development exclusively in containers, using either VS code or Theia in a browser. And with C# we are almost there, I just think issues like this needs a bit more focus.

[filipw]

I just think issues like this needs a bit more focus.

like I said, it's not impossible, it just means we would need to have a dual model:

• "full" version that supports Unity and desktop based MSBuild tasks
• "light" version that only works with .NET Core / .NET 5 development

The major problem, however, is that with how things stand at the moment debugger and test execution are also coupled to "full" version due to VS dependencies. Under the hood OmniSharp is not really fully independent of VS.

[Spongman]

"full legacy" version that supports Unity and desktop based MSBuild tasks
"light modern" version that works with .NET Core / .NET 5 development

[rickardp]

Any updates on this subject. Dragging along the full mono-devel dependency for this is becoming increasingly heavy for a very small gain in functionality, especially now with .net 5 and .net 6 on the way. Maybe maintaining the current version for Unity and focusing on .net-framework-less .net 5/6 for future development would make sense?

[filipw]

Dragging along the full mono-devel dependency for this is becoming increasingly heavy

OmniSharp ships with its own custom build of Mono which is only ~5MB in size, so I wouldn't call this "heavy"
In fact, OmniSharp built as self-contained .NET 5.0 application is much larger than the current distributable.

However, yes there is a plan for .NET 5.0 (probably already 6.0) version.
The feature branch is here https://github.com/OmniSharp/omnisharp-roslyn/tree/demo/net50

FWIW I am running it daily for all my development these days and it seems quite stable 😊It is also a drop-in replacement for the version used at the moment in terms of extension compatibility. Though we don't have a fixed plan when it will be available.

[rickardp]

@filipw As other people pointed out earlier, the embedded version isn't portable. For example IIRC there's still not an aarch64 version (maybe fixed now?) and it's not compatible with Alpine Linux.

For a .net 5 dev container, removing the Mono dependency makes a lot of sense.

Sounds promising that there is work on .net 5/6 support though!

[Mithras]

hey @filipw,
I'm trying to build demo/net50 to try it out and it seems to build just fine but it fails to publish:

I'm running these to build:

docker run -v "/c/s/omnisharp-roslyn/:/src" -it --rm mono:latest
cd /src
./build.sh --target Quick --configuration Release

Am I doing something wrong?

[filipw]

The generic publish task doesn't work on that branch, try running ./build.sh --target PublishNet5Builds --configuration Release

Also, I am not sure it will work on Linux - I've only been using it on a Mac 🙂

[Mithras]

That worked, thank you!

Now I'm having another issue. There are dozens of this exceptions in the log and no intellisense at all:

File name: 'NuGet.Frameworks, Version=5.9.1.8, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
   at Microsoft.NET.Build.Tasks.ProcessFrameworkReferences.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)

[info]: OmniSharp.MSBuild.ProjectManager
        Loading project: /workspace/EcoManager/Public.ApplicationServices.Core/Public.ApplicationServices.Core.csproj
[fail]: OmniSharp.MSBuild.ProjectLoader
        The "ProcessFrameworkReferences" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'NuGet.Frameworks, Version=5.9.1.8, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.

I don't have NuGet.Frameworks anywhere in my code. Should I add it somewhere?

[Mithras]

I do have 3 of them though

[Mithras]

Any ideas why demo/net50 doesn't work for me? Main releases crash every couple hours and eat all my CPU in between crashes. I really want to try pure .NET 5 build.

[616b2f]

demo/net50 is gone is there any replace for it? I would like to test it.

[filipw]

yes https://github.com/OmniSharp/omnisharp-roslyn/tree/feature/omnisharp-vnext

[Mithras]

yes https://github.com/OmniSharp/omnisharp-roslyn/tree/feature/omnisharp-vnext

Cool. Do I need to specify some special target or just ./build.sh --target Quick --configuration Release should work?
I tried:

docker run -v "/c/s/omnisharp-roslyn/:/src" -it --rm mono:latest
cd /src
./build.sh --target Quick --configuration Release

and it worked

THere were a couple errors though:

but it doesn't work when I try to use it:

it is the correct path:

Am I missing something?

[filipw]

you should set omnisharp.path to "omnisharp.path": "{your cloned directory}/artifacts/publish/OmniSharp.Stdio.Driver/osx-x64/net5.0/OmniSharp" where osx-x64 should be replaced by the relevant platform folder that was created

However it was only tested on Windows and MacOS so far so not sure if it will work on Linux

[filipw]

Yes, as I said, you should find the published x-plat under artfiacts in the platform specific folder. In this case I have no idea what you have under opt, because we never publish anything there and why is it lowercase - all OmniSharp files are pascal cased. The entry point on Linux/Mac is called OmniSharp.

The steps are:

1. run ./build.sh --target Quick --configuration Release or even better ./build.sh --target PublishNet5Builds --configuration Release (the latter, despite the name, will be quicker)
2. set omnisharp.path to "omnisharp.path": "{your cloned directory}/artifacts/publish/OmniSharp.Stdio.Driver/osx-x64/net5.0/OmniSharp" where osx-x64 should be replaced by the relevant platform folder that was created for you

If it doesn't work, then it is because this branch is not supported 😀

[Mithras]

We are using Linux dev containers to do all development so if it doesn't work on Linux it's not something I can test or use.

I have no idea what you have under opt

I just mapped artifacts there:

so it's whatever I got after building in /omnisharp-roslyn/artifacts/publish/OmniSharp.Stdio.Driver/linux-x64/net5.0

or even better ./build.sh --target PublishNet5Builds --configuration Release

I'll try this one

[Mithras]

./build.sh --target PublishNet5Builds --configuration Release is definitely much faster:

but still the same

[filipw]

as I wrote before this is not really an OmniSharp error, it means your configuration is incorrect and you are pointing to a non-existing path. "omnisharp.path" should not be set to a folder in which OmniSharp is found, but to the path to the executable which is called OmniSharp

[Mithras]

I'm just doing what's written in the readme. Not sure what path you are talking about.

[filipw]

your screenshot showed you set "omnisharp.path":"/opt/omnisharp". Assuming your artifact folder is /opt/omnisharp ,you should set it to "omnisharp.path":"/opt/omnisharp/OmniSharp" because the executable is named OmniSharp

[Mithras]

Ok, that was my problem. It starts now:

And then I get 50 of these:

[fail]: OmniSharp.MSBuild.ProjectLoader
        The "ProcessFrameworkReferences" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'NuGet.Frameworks, Version=5.11.0.10, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.

File name: 'NuGet.Frameworks, Version=5.11.0.10, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
   at Microsoft.NET.Build.Tasks.ProcessFrameworkReferences.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)
[warn]: OmniSharp.MSBuild.ProjectManager
        Failed to load project file '/workspace/EcoManager/Infrastructure/Infrastructure.csproj'.
/workspace/EcoManager/Infrastructure/Infrastructure.csproj
/usr/share/dotnet/sdk/5.0.400/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(89,5): Error: The "ProcessFrameworkReferences" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'NuGet.Frameworks, Version=5.11.0.10, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.

File name: 'NuGet.Frameworks, Version=5.11.0.10, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
   at Microsoft.NET.Build.Tasks.ProcessFrameworkReferences.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)

and nothing works

[filipw]

This is because you have SDK 5.0.400 installed, and at the moment this branch is pinned to 5.0.302 and won't support anything newer.

[Mithras]

ok, I'll try it with older SDK later. Is there a reason it's pinned to a specific version?

[Mithras]

I'll try it with older SDK later

or not. I don't feel like randomly trying all of these to find which one has 5.0.302
Please update the issue when the branch supports newer SDKs.

[Mithras]

Just in case somebody else is interested in trying this. @filipw has updated the branch to 5.0.401 so I was able to test it with dotnet dev container our team is using. It works A LOT better than the Mono one. It's faster and doesn't bug out every couple hours like Mono does. Thank you @filipw!

[vchirikov]

If you don't need to use csx/cake, you can use my fork of omnisharp.
I cut them off and migrated the code to the net6.0 (+ some minor updates like ilspy/msbuild etc).
dotnet publish -c Release -o artifacts/omnilight +

"omnisharp.path": "<RepoRootPath>\\artifacts\\omnilight\\OmniSharp.exe",

p.s. I use it with 6.0.100-rc.2.21505.57

[Mithras]

Also, is it expected that Omnisharp breaks even when patch version of SDK changes? E.g. 5.0.401 works but 5.0.402 does not. I've tried to find/replace all 5.0.401 with 5.0.402 but it still doesn't work. Is there a guide what exactly do I need to change to make it work with a specific SDK version?

[filipw]

This is a current limitation, because OmniSharp loads NuGet assemblies for its own purposes. On the vNext branch (currently .NET 5, to be .NET 6) it would use MSBuild from SDK and it is possible that after an SDK update, the SDK would have newer NuGet binary dependencies that what OmniSharp has and that is the reason for the error.

[Mithras]

This is a current limitation, because OmniSharp loads NuGet assemblies for its own purposes. On the vNext branch (currently .NET 5, to be .NET 6) it would use MSBuild from SDK and it is possible that after an SDK update, the SDK would have newer NuGet binary dependencies that what OmniSharp has and that is the reason for the error.

Yep, I understand this. I'm trying to figure out what changes do I need to make to get it working with newer SDK versions. Do I need to update NuGet packages? Get newer Nuget binaries somewhere? What do I do to make it work with newer SDKs? Our team is required to update containers from time to time because of vulnerabilities and I don't want to be blocked from doing so because I don't know how to build Omnisharp.

[filipw]

resolved by #2291