Can no longer run under WSL

[nickspoons]

Under 1.53.3, OmniSharp-roslyn can no longer load solutions containing more than a single project under WSL. That is to say, from the WSL "Linux" filesystem, executing a Windows OmniSharp-roslyn build, which is extremely useful functionality provided by OmniSharp-vim.

I have bisected this to c88ed90 introduced in #1820

The example solution I've been testing on is this repo, using a server built in Visual Studio.

cd /mnt/c/code/external/omnisharp-roslyn
bin/Debug/OmniSharp.Stdio.Driver/net472/OmniSharp.exe -v > output

Log from commit c88ed90: https://pastebin.com/raw/GnfrtYrn

Log from previous commit 319d9cb: https://pastebin.com/raw/dD5RgMsi

The important difference is that in c88ed90, the server only loads a single project and then stops.

Running bin/Debug/OmniSharp.Stdio.Driver/net472/OmniSharp.exe -v by itself results in a full server output - all projects are loaded as expected. However, when stdout is written to a file (> outfile) or when the server is started as a stdio job with outputs captured by the editor then the above failure occurs.

[filipw]

thanks for tracking down the commit.
To be honest, this is something we never paid any attention to support - loading Windows paths from WSL? I didn't even realize it's possible 😀

anyway let's cc: @JoeRobich who introduced this change for telemetry purposes in VS Code

[nickspoons]

The error occurs the 2nd time this line is reached: src/OmniSharp.Host/Services/DotNetCliService.cs#L140 - the server hangs, waiting for the dotnet --info process to finish (the first dotnet --info completes normally).

The changed behaviour is due to src/OmniSharp.MSBuild/ProjectFile/ProjectFileInfo.cs#L119.

[nickspoons]

Running this external process is clearly a WSL issue, and I've run into it before - we can't run tests via OmniSharp-roslyn in OmniSharp-vim under WSL either, as they are also run as external dotnet ... commands. And adding workarounds for running the Windows server from the WSL filesystem may not be desirable (although I personally do most of my work in this environment and I certainly hope to continue using OmniSharp-roslyn in this way).

However, in this case the change is purely for VSCode telemetry, which we make no use of in OmniSharp-vim (or presumably other clients), and in fact it slows down initialisation of OmniSharp-roslyn. I have added crude profiling (adding DateTime.Now around this block ) and started the server a few times - first at c88ed90 and then with this change to src/OmniSharp.MSBuild/ProjectFile/ProjectFileInfo.cs#L119:

// var dotNetInfo = dotNetCli.GetInfo(Path.GetDirectoryName(projectInstance.FullPath));
var dotNetInfo = DotNetInfo.Empty;

Before the change it takes 20-21 seconds for this block to load the projects of OmniSharp.sln. After the change it takes 15-16 seconds. This is significant, for extra information that we are not interested in.

Is it feasible to add a command line flag to disable this lookup? Perhaps it makes even more sense to make it an opt-in feature rather than opt-out, as only VSCode is interested in these results?

[filipw]

yep that is a good suggestion, in fact we can feature flag the entire changeset from that PR