[Bug]: Cannot load projects in C# Dev Kit due to StableStringHash error

[timheuer]

Issue Description

Loading a project in C# Dev Kit (VSCode) and Solution Explorer is failing to load:

Steps to Reproduce

Install VS 17.9 int.preview which is getting preview SDK for 8.0.200 builds
Open a folder in C# Dev Kit

Expected Behavior

Project loads fine (this is a regression)

Actual Behavior

No solution explorer loads, no roslyn project context exists

Analysis

No idea.

I've implmeneted this workaround in my csproj file:

  <PropertyGroup Condition="'$(BuildingInsideVisualStudio)' != 'true'">
    <CopyUpToDateMarker>$([MSBuild]::NormalizePath('$(MSBuildProjectDirectory)', '$(IntermediateOutputPath)', '$(MSBuildProjectFile).CopyComplete'))</CopyUpToDateMarker>
    <MSBuildCopyMarkerName>$(MSBuildProjectFile)</MSBuildCopyMarkerName>
  </PropertyGroup>

Versions & Configurations

dotnet info:

.NET SDK:
 Version:           8.0.200-preview.23604.9
 Commit:            a75f89274d
 Workload version:  8.0.200-manifests.3b83835e

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22635
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\8.0.200-preview.23604.9\

.NET workloads installed:
 Workload version: 8.0.200-manifests.3b83835e
 [maui-windows]
   Installation Source: VS 17.9.34412.211
   Manifest Version:    8.0.3/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.maui\8.0.3\WorkloadManifest.json
   Install Type:        FileBased

 [android]
   Installation Source: VS 17.9.34412.211
   Manifest Version:    34.0.52/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.android\34.0.52\WorkloadManifest.json
   Install Type:        FileBased

 [aspire]
   Installation Source: VS 17.9.34412.211
   Manifest Version:    8.0.0-preview.1.23557.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.0.0-preview.1.23557.2\WorkloadManifest.json
   Install Type:        FileBased

 [maccatalyst]
   Installation Source: VS 17.9.34412.211
   Manifest Version:    17.0.8490/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.maccatalyst\17.0.8490\WorkloadManifest.json
   Install Type:        FileBased

 [ios]
   Installation Source: VS 17.9.34412.211
   Manifest Version:    17.0.8490/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.ios\17.0.8490\WorkloadManifest.json
   Install Type:        FileBased


Host:
  Version:      8.0.0
  Architecture: x64
  Commit:       5535e31a71

.NET SDKs installed:
  8.0.200-preview.23604.9 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.14 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

msbuild -version:

MSBuild version 17.9.0-preview-23612-07+5af9301a6 for .NET Framework
17.9.0.61207

[timheuer]

@JanKrivanek I saw this PR (#9387) and I'm getting some broken behavior now on VSCode

[v-Judy]

This issue also repro in the 9.0.100-alpha.1.23613.5 on Linux/Mac OS.

[JanKrivanek]

tl;dr;: can you please update your sdk? (fresh version - wasn't avaialble at the time you hit this).

This looks to be sdk version mismatch (or rather a stale insertions of msbuild main -> sdk main / sdk 8.0.2xx), that should be resolved as of now:

• main: [main] Update dependencies from dotnet/msbuild sdk#37479, build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2335415&view=results, version: 9.0.100-alpha.1.23613.12
• 8.0.2: insertion PR: [release/8.0.2xx] Update dependencies from dotnet/msbuild sdk#37484, build: https://dev.azure.com/dnceng/internal/_build/results?buildId=2335334&view=results, version: 8.0.200-preview.23613.8

[JanKrivanek]

I confirm that I'm able to repro the issue via the latest VisualStudioClient devbox (it still has 8.0.200-preview.23604.9 sdk) and attempting to open pre-existing project (doesn't work on dotnet new console project).

The issue is resolved by installing latest 8.0.2 sdk

The issue reappers after removing the latest sdk.

---

Btw. regardless of this specific case - it still would be interesting to know why StringTools failed to load. I'll try to look into that

[JanKrivanek]

So tracing down the issue I can see in assemblyloader etw that the called assembly was loaded from: %USERPROFILE%\.vscode\extensions\ms-dotnettools.csdevkit-1.1.16-win32-x64\components\vs-green-server\platforms\win32-x64\node_modules\@microsoft\visualstudio-server-shared.win32-x64\Microsoft.NET.StringTools.dll

Since it was called from local sdk with mismatched version, it's expected that the called function was not found (it existed in Microsoft.NET.StringTools.dll in the sdk).

@tmeschter - is it expected that the project system calls into sdk, but resolves loads from visualstudio-server-shared.win32-x64? I suppose customers can freely upgrade/downgrade their sdks and the vscode modules cannot be guaranteed to be in sync. Or did I misunderstood anything?
I have etw trace with the assembly loads available if that can be of any help.

[marcpopMSFT]

Was this only a temporary issue or is it something we have to watch out for going forward with VS insertions? For 8.0.2xx (and 3xx/4xx), we typically just pick the latest builds to insert into VS. Would us updating the version in main be sufficient?

We have an open PR to update the version to the 23613.10 version of the SDK if that's sufficient.

@richaverma1 since we may need to be careful in testing 2xx insertions for the next few weeks.

[rainersigwald]

We have an open PR to update the version to the 23613.10 version of the SDK if that's sufficient.

Experiments from me and @timheuer suggest this is good.

We should spend some time understanding why ALC isolation isn't letting the devkit components that ship with devkit be older/different than the StringTools the SDK MSBuild uses.

[JanKrivanek]

Marking as fixed as the immediate issue is resolved.

The rootcause investiagation and fixing will be tracked by: #9572