Omnisharp-vscode: .net-core project constantly needs to restore if build/test happening in WSL/bash

[mipnw]

Environment data

WSL\bash $dotnet --info

.NET Command Line Tools (2.0.3)
Product Information:
 Version:            2.0.3

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.0.3/

Microsoft .NET Core Shared Framework Host
Version  : 2.0.3

Windows\cmd.exe dotnet --info

.NET Command Line Tools (2.1.4)
Product Information:
 Version:            2.1.4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.4\

Microsoft .NET Core Shared Framework Host
  Version  : 2.0.5

VS Code version:1.20.0
C# Extension version: 1.14.0

Steps to reproduce

• In VS Code open a NET CORE 2.0 C# app folder containing an SLN file, and two subfolders, each containing one CSPROJ file.
• C# Extension works, intellisense and navigating between symbols works
• In VS Code internal terminal (wsl\bash), or in an external terminal (wsl\bash) do a dotnet build
• Almost immediately 100% of the source code turns red with squigglies, intellisense goes kapput. And shortly thereafter two info boxes popup in VS Code each saying "There are unresolved dependencies from src\Project.csproj. Please execute the restore command to continue.", one for each CSPROJ.
• Clicking the Restore button makes the C# extension work again after ~15-20 seconds.
• Interestingly, "dotnet restore" in the shell (whether internal terminal or external terminal) does not help the C# extension.
  By the way, restore shouldn't even be needed since this bug repros even if you have not added any new dependencies on nuget packages since the last build, nor edited the CSPROJ, nor edited the SLN. Actually even if you don't edit anything, and rebuild with "dotnet build" that build basically does nothing, but C# extension still goes kaput until you click the info boxes "Restore" buttons and wait.

This bug does not seem to repro if I dotnet build or dotnet test in cmd.exe, it only repros if I do in WSL/bash (internal or external terminal)

For that reason this bug could actually be in .NET CORE SDK for Linux, or perhaps in Windows Subsystem For Linux. I don't really know enough about what's causing this to decide whether to open this issue with those teams instead.

Expected behavior

The C# extension doesn't go kaput while a background task is building the project.
I build very frequently, including using CTRL-SHIFT-B a key binding to a VSCode task set to "dotnet build", and each time the project goes dead until the build is over + 15-20 seconds to restore. Why?

Actual behavior

The C# extension goes kaput each time you dotnet build.

[micahj]

Hey @mipnw did you ever get any resolution to this?
Cheers

[jbatte47]

I am experiencing the same issue when running dotnet run and/or dotnet restore from within a Docker container, when the source files are mapped as a volume to my local source directory. It seems that when anything other than VSCode performs a restore, OmniSharp perceives this as having its required assets altered or moved and needs to restore them. Currently trying to determine exact file paths used so that I can perhaps have my non-VSCode restore commands explicitly avoid those locations. It seems to be happening regardless of the content of my bin and obj folders.

[dkdewitt]

Was this ever resolved? Can't use WSL and VSCode currently as ther conflicts between WSL and WIndows are causing all .NET objects to not be found.

[rchande]

cc @akshita31

[akshita31]

@mipnw @dkdewitt Thank you for taking time to inform us of the issue and apologize for the delay here .We are able to reproduce this and are working on it.

[akshita31]

I am looking into this now. For now, until we find a fix, F1 --> Restart OmniSharp should restore the extension to a sane state.

[akshita31]

Diving further into this issue:

1. When you execute "dotnet build" inside a WSL/docker the paths contained inside the build assets are all resolved with respect to mount path inside the docker/WSL. Eg: In my case I was mounting the directory in a "Sources" folder hence in my nuget.g.props contained the "ProjectAssetsPath" as /Sources/test/obj/project.assets.json

2. OmniSharp checks these paths to check whether build assets exist or a restore is needed. In my case it was interpreting the path as "C://Sources/test/obj/project.assets.json". This path doesn't exist hence it says that there are "Unresolved dependencies".

There is no way for omnisharp here to be able to resolve the paths to the file on disk unless a restore is performed, hence there are two options:

1. OmniSharp does the auto restore whenever it doesnt find these build assets. This would make intellisense work properly, however the build assets that you generated inside your WSL will be overwritten and there would be side affects that will be hard to understand and debug

2. OmniSharp prompts the users that they must do a restore in order for the intellisense to work, hence the users will be aware that a restore step is happening and will hence be aware of the files being changed.

The second approach is what we are adopting now and both me and @rchande agree that it is the more obvious and less error-prone behavior.

@mipnw Does that make sense?

[jeffhube]

I wonder if it would be possible to have NuGet use paths that vary by platform, so that doing a restore under WSL wouldn't clobber the files written by the host?