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

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

[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.