Beta 4 is reading F# projects again and reporting syntax errors on F# code

[NinoFloris]

Environment data

dotnet --info output:
.NET Command Line Tools (2.0.0)

Product Information:
Version: 2.0.0
Commit SHA-1 hash: cdcd1928c9

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

Microsoft .NET Core Shared Framework Host

Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d
VS Code version:
C# Extension version:

Omnisharp is running on mono 5.4 (system wide install)

Steps to reproduce

Just add an F# project under your project root

Expected behavior

Ignore the project and its files.

Related:
#1571

[DustinCampbell]

I think I can guess the issue here. This is an F# project that is referenced by a C# project, correct? Or does an F# by itself get loaded?

[NinoFloris]

Yes just a lib in the tree

[DustinCampbell]

C# for VS Code won't even activate unless there's a .csproj or .sln file in the tree. Could you provide your OmniSharp Log? Select View->Output to display the output pane and then select "OmniSharp Log" from the drop-down in the top-right corner.

[DustinCampbell]

FWIW, I just created an F# project in a folder with an sln file and cannot reproduce the issue. Here's what I did at the command-line:

> dotnet new classlib -lang F#
> dotnet new sln
> dotnet sln add test-fsharp.fsproj
> code .

Do you have further repro steps or project that reproduces the issue?

[NinoFloris]

It's definitely omnisharp, removing beta4 and going back to stable obviates the problem, we see this with multiple solutions btw. All having a structure like:

Core
|
Core.FSharp
|
Host

and all have an sln.

[DustinCampbell]

Do you have a project that you could share that reproduces the issue? OmniSharp has code like this:

https://github.com/OmniSharp/omnisharp-roslyn/blob/master/src/OmniSharp.MSBuild/MSBuildProjectSystem.cs#L163

and this:

https://github.com/OmniSharp/omnisharp-roslyn/blob/master/src/OmniSharp.MSBuild/MSBuildProjectSystem.cs#L134

Which only look at *.csproj files.

[NinoFloris]

I'll try to see if I can isolate the conditions

[DustinCampbell]

Thanks!

[NinoFloris]

Hmm creating a c# console app referencing an f# lib is already enough to trigger it for me, no sln.

[DustinCampbell]

OK. Yes, that was what I expected, Thanks! I misunderstood your comment here:

Yes just a lib in the tree

I thought that meant that just an F# lib would reproduce the issue.

[NinoFloris]

Ah no just one f# project in a c# tree ;)

[NinoFloris]

Ok very important, mono 5.4 seems to have something to do with this.
After running brew cask uninstall mono-mdk and restarting omnisharp the problem is gone.
Installing mono 5.4 and doing an omnisharp restart introduces it again.

So yay, omnisharp's first version that tries to use the machine global mono install gets hosed ;)

[DustinCampbell]

I'm pretty sure that's just because the F# SDK for .NET Core is included in Mono 5.4.

[NinoFloris]

Oh noes

[DustinCampbell]

Also, note that we only started running OmniSharp on the globally-installed Mono with the latest C# for VS Code betas. So, it's possible this is just an OmniSharp bug that is now exposed.

[NinoFloris]

I'm aware. That's why I knew of it in the first place, I actually installed mono 5.4 to get some lower omnisharp startup times

[DustinCampbell]

@NinoFloris : I just wanted to let you know that I just released on a new beta of C# for VS Code that should fix this issue: 1.3.0-beta5. You can following these instructions if you're interested in trying it out.