On Linux OmniSharp is started with Mono even if told not to

[fogzot]

I am trying to open a dotnet core msbuild project with VS Code on Linux and everything works, except that the extension marks as not found all the assemblies that come with the netcoreapp1.0 framework and as "wrong version" the ones that have a compatible name in the Mono .NET 4.5 framework.

I guess this happens because the extension starts OmniSharp with Mono even if dotnet is correctly installed and the configuration option omnisharp.useMono is set to false.

Here is OmniSharp starting:

Starting OmniSharp server at 02/12/2016, 10:55:44
    Target: /home/fog/Workspaces/wok/scratch/test1

OmniSharp server started wth Mono
    Path: /home/fog/.vscode-insiders/extensions/ms-vscode.csharp-1.5.3/bin/run
    PID: 18513

OmniSharp: -s /home/fog/Workspaces/wok/scratch/test1 --hostPID 16021 --stdio DotNet:enablePackageRestore=false --encoding utf-8
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.Startup","Message":"Omnisharp server running using Stdio at location '/home/fog/Workspaces/wok/scratch/test1' on host 16021."},"Seq":1,"Type":"event"}
[INFORMATION:OmniSharp.DotNet.DotNetProjectSystem] Initializing in /home/fog/Workspaces/wok/scratch/test1
[INFORMATION:OmniSharp.DotNet.DotNetProjectSystem] Auto package restore: False
[INFORMATION:OmniSharp.DotNet.DotNetProjectSystem] Update workspace context
[INFORMATION:OmniSharp.DotNet.DotNetProjectSystem] Resolving projects references
[INFORMATION:OmniSharp#MSBuild] No solution files found in '/home/fog/Workspaces/wok/scratch/test1'
[INFORMATION:OmniSharp#ProjectFileInfo] Using TargetFrameworkRootPath: /usr/lib/mono/xbuild-frameworks
[INFORMATION:OmniSharp#ProjectFileInfo] Using tools version: 15.0
[INFORMATION:OmniSharp#MSBuild] Add project: /home/fog/Workspaces/wok/scratch/test1/test1.csproj
[INFORMATION:OmniSharp#MSBuild] Update project: test1
[INFORMATION:OmniSharp.Startup] Configuration finished.

Environment data

dotnet --info output:
.NET Command Line Tools (1.0.0-preview3-004056)
Product Information:
Version: 1.0.0-preview3-004056
Commit SHA-1 hash: ccc4968bc3
Runtime Environment:
OS Name: debian
OS Version:
OS Platform: Linux
RID: debian.8-x64

VS Code version:
Code Insiders 1.8.0-1480662019

C# Extension version:
1.5.3

Steps to reproduce

1. create a new web project with dotnet new -t web
2. restore packages with dotnet restore
3. open it using VS Code

Expected behavior

All framework assemblies are correctly resolved, no warnings about missing assemblies or versions.

Actual behavior

Errors like:

file: 'file:///home/fog/Workspaces/wok/scratch/test1/server/src/Program.cs'
severity: 'Warning'
message: 'Assuming assembly reference 'System.Runtime, Version=4.0.20.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' used by 'Microsoft.AspNetCore.Hosting.Abstractions' matches identity 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' of 'System.Runtime', you may need to supply runtime policy [test1]'
at: '14,24'
source: ''

[DustinCampbell]

That's actually by design. The "omnisharp.useMono" setting only functions when you've also used the "omnisharp.path" setting to use a custom OmniSharp.

The warning that you're getting has nothing to do with the fact that OmniSharp is running on Mono. The runtime on which OmniSharp runs and the location of the reference assemblies it uses are orthogonal (i.e. it doesn't pick reference assemblies from Mono for .NET Core projects).

I suspect you're seeing the CS1701 warning from C# the compiler which all tools generally suppress (including Visual Studio). This was original reported in #967. We've recently fixed this problem for 1.6. Please try the latest beta version to see if that addresses the problem for you. See this page for information on installing beta releases

[fogzot]

The line that made me think it was a Mono-related problem was:

[INFORMATION:OmniSharp#ProjectFileInfo] Using TargetFrameworkRootPath: /usr/lib/mono/xbuild-frameworks

in the OmniSharp log (note the /usr/lib/mono/xbuild-frameworks path). Anyway, I'll try the beta and let you know.

Thanks.

[fogzot]

I confirm the beta solves the problem. Thanks again.

[DustinCampbell]

Excellent! Very glad to hear it!

Yes, the TargetFrameworkRootPath is set to Mono to ensure that desktop targets and tasks for MSBuild get picked up when you open such a project. However, .NET Core targets and tasks are pulled in through NuGet.