CSC hangs for 20 seconds when run with /shared argument on .NET SDK 8.0.200

[joncham]

Describe the bug

The used of the csc /shared argument causes a 20 second delay/hang.

This seems to be a regression from 8.0.1.

To Reproduce

Using the 8.0.200 SDK

Measure-Command { .\dotnet.exe sdk\8.0.200\Roslyn\bincore\csc.dll /shared /? }  

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 20
Milliseconds      : 104
Ticks             : 201047737
TotalDays         : 0.000232694140046296
TotalHours        : 0.00558465936111111
TotalMinutes      : 0.335079561666667
TotalSeconds      : 20.1047737
TotalMilliseconds : 20104.7737


Measure-Command { .\dotnet.exe sdk\8.0.200\Roslyn\bincore\csc.dll /? }        

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 75
Ticks             : 751743
TotalDays         : 8.70072916666667E-07
TotalHours        : 2.088175E-05
TotalMinutes      : 0.001252905
TotalSeconds      : 0.0751743
TotalMilliseconds : 75.1743

Exceptions (if any)

Further technical details

• Include the output of dotnet --info
• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

.\dotnet.exe --info
.NET SDK:
 Version:           8.0.200
 Commit:            438cab6a9d
 Workload version:  8.0.200-manifests.cdf2cc8e

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win-x64
 Base Path:   <redacted>\sdk\8.0.200\

.NET workloads installed:
There are no installed workloads to display.

Host:
  Version:      8.0.2
  Architecture: x64
  Commit:       1381d5ebd2

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[xoofx]

Wondering if it belongs here or it's more for https://github.com/dotnet/roslyn, @jaredpar maybe you might know?

[jaredpar]

Do you have a perf trace of this anywhere, or a dump when it hangs?

I'm not able to reproduce this locally. Tried a few variations of the commands.

[joncham]

@jaredpar do you want file attached here or is there some place to upload or send?

[joncham]

Debugging a bit locally, and I see the call here to CreateNamedPipeClient repeatedly fail and return Interop.Errors.ERROR_FILE_NOT_FOUND

[jaredpar]

Do you see what the value of _normalizedPipePath is at that location? For that to happen and having the 20 second timeout I would expect that the compiler server is actually failing to start in this scenario. Under the hood /shared is starting the server if it doesn't exist yet and it will end up waiting ~20 seconds for it to establish a named pipe. Guessing that is what's happening here.

[joncham]

The value of _normalizedPipePath is \\.\pipe\A3e62qkUmq+JJ8FWJ7uk5QQGtvwg_ahrh712xdcr_sc

[joncham]

After debugging a bit more, it seems like the issue is that we are using a zip/binary deployment of the SDK. We do not have 8.0.200 installed on the machine. The server launch uses the system path to dotnet.exe. So, when I run:

<path to sdk>\dotnet.exe <path to sdk>\sdk\8.0.200\Roslyn\bincore\csc.dll /shared /?   

It tries to run the following to launch the server:

"C:\Program Files\dotnet\dotnet.exe" exec "<path to sdk>\dotnet-8-sdk-win-x64\sdk\8.0.200\Roslyn\bincore\VBCSCompiler.dll" "-pipename:A3e62qkUmq+JJ8FWJ7uk5QQGtvwg_ahrh712xdcr_sc"

And this fails with error:

You must install or update .NET to run this application.
App: <path to sdk>\dotnet-8-sdk-win-x64\sdk\8.0.200\Roslyn\bincore\VBCSCompiler.dll
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '8.0.2' (x64)
.NET location: C:\Program Files\dotnet\

The following frameworks were found:
  5.0.17 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  6.0.26 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  7.0.15 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  8.0.1 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Learn more:
https://aka.ms/dotnet/app-launch-failed

[jaredpar]

Unfortunately I'm not sure what we can do here. There isn't really an API for "get me the path to the host process" so not sure how to re-use the existing dotnet.exe / dotnet here to launch the server.

Been discussed in dotnet/runtime before but don't think we came to a resolution.

dotnet/runtime#88754

@agocke, @ericstj

[xoofx]

Unfortunately I'm not sure what we can do here. There isn't really an API for "get me the path to the host process" so not sure how to re-use the existing dotnet.exe / dotnet here to launch the server.

So, as a workaround, does that mean that in order to setup a dotnet environment correctly with a custom dotnet SDK path, we need to both set DOTNET_HOST_PATH and PATH accordingly? (As it looks like Roslyn is probing first for DOTNET_HOST_PATH here)

[jjonescz]

we need to both set DOTNET_HOST_PATH and PATH accordingly

Yes, but you can also just set PATH accordingly (pointing to the custom SDK first) and DOTNET_HOST_PATH can be unset, I think.