[ISSUE] - ProjectInitializationStatusService Failed

[ComputerMaster1st]

Describe the Issue

Currently using "Remote SSH" extension to write code remotely. However, I'm seeing the following error when loading the project: Failed to listen to project initialization status: Error: Activating the "Microsoft.VisualStudio.ProjectSystem.ProjectInitializationStatusService (0.1)" service failed.

I have already tried the C# Dev Kit uninstalled and C# extension alone appears to be fine. However, the issue rises when the dev kit is installed and enabled. As a result of the error, IntelliCode also fails to work properly (if at all).

It did all work fine before an update was pushed for either the dev kit or vscode. Downgrading and even using pre-release builds yielded no changes with the error.

Full Output Logs:

C#:

Using dotnet configured on PATH
Dotnet path: /usr/share/dotnet/dotnet
Activating C# + C# Dev Kit + C# IntelliCode...
waiting for named pipe information from server...
[stdout] {"pipeName":"/tmp/b9dcaf20.sock"}
received named pipe information from server
attempting to connect client to server...
client has connected to server
[Info  - 2:26:01 AM] [Program] Language server initialized

C# Dev Kit:

Starting Spawn .NET server...
Starting Open a solution...
Starting Open a solution with environment service...
Starting Clear environment...
Using preinstalled .NET runtime at "/usr/share/dotnet/dotnet"
.NET server started and IPC established in 1431ms
Completed Spawn .NET server (1729ms)
Completed Clear environment (2332ms)
Completed Open a solution with environment service (2393ms)
Starting Restore solution...
Completed Open a solution (2485ms)
Starting NuGet restore for the solution.
Starting command: "dotnet" restore /home/nekoputer/Discord/Kuroko_Src/Kuroko.sln --interactive...
Failed to listen to project initialization status: Error: Activating the "Microsoft.VisualStudio.ProjectSystem.ProjectInitializationStatusService (0.1)" service failed.
Completed command: "dotnet" restore /home/nekoputer/Discord/Kuroko_Src/Kuroko.sln --interactive (1343ms)
Completed NuGet restore.
Completed Restore solution (1346ms)

Dotnet --Info:

.NET SDK:
 Version:           8.0.104
 Commit:            034f91fcc0
 Workload version:  8.0.100-manifests.cd97f1c9

Runtime Environment:
 OS Name:     arch
 OS Version:  
 OS Platform: Linux
 RID:         arch-x64
 Base Path:   /usr/share/dotnet/sdk/8.0.104/

.NET workloads installed:
 Workload version: 8.0.100-manifests.cd97f1c9
There are no installed workloads to display.

Host:
  Version:      8.0.4
  Architecture: x64
  Commit:       2d7eea2529

.NET SDKs installed:
  8.0.104 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.NETCore.App 8.0.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Any assistance is greatly appreciated.

Steps To Reproduce

Install Remote SSH extension for VSCode
Connect to remote host
Create/Load Project

Expected Behavior

Projects load normally and IntelliCode works as normal.

Environment Information

Remote Host: Arch Linux
Local Hosts: MacOS 14.4.1 & Windows 11
VSCode Version: 1.89.1

C#: v2.28.11
C# Dev Kit: v1.5.20
IntelliCode for C# Dev Kit: v2.1.11
Remote - SSH: v0.110.1

[xenapior]

Same error here.
Manually switching back to C# Dev Kit v1.4.29 solves the problem.

[ComputerMaster1st]

Same error here. Manually switching back to C# Dev Kit v1.4.29 solves the problem.

Can confirm, this resolved the issue for now. I didn't check other cs files after downgrading initially so that was dumb on my part. So after downgrading, close & reopen files for it to start working if you have any open already.
In addition to this, it appears from my case, only remote is affected. Local seems fine with newer version of C# Dev Kit. I can only guess the newer version doesn't like remote connections at the moment.

[arunchndr]

Note: This looks like a regression in v1.5.20.

[kvenkatrajan]

@tmeschter/ @lifengl can you have a look please?

[lifengl]

@xenapior : this is clearly a problem because ASP.NET runtime is not installed on the machine. It invalidated our assumption that the ASP.NET runtime would be installed along with the SDK. (@xenapior , it would help us to understand how it gets there in the first place, like, did you download the SDK from a specific source, etc...)

The ASP.NET dependency was added to support HTTPS channel, which might not be essential for all users. We will find a fix for that.

[baronfel]

@lifengl for Arch Linux it looks like they chose to package the components more discretely:

• dotnet-sdk brings the SDK components
• dotnet-runtime brings the .NET Runtime
• aspnet-runtime brings the ASP.NET Runtime

This is the case on other Linux distros as well, but often users install the SDK via a 'meta package' that references all three of these core components. If there is any Arch-specific documentation for DevKit we could call this out.

@ComputerMaster1st can you install aspnet-runtime and see if that fixes your scenario when using the latest DevKit?

[lifengl]

this is essentially a dup of #840

and thanks, @baronfel , this appears to be the problem. The simple assumption that SDK carrying both runtime is incorrect...

[ComputerMaster1st]

@lifengl for Arch Linux it looks like they chose to package the components more discretely:

• dotnet-sdk brings the SDK components
• dotnet-runtime brings the .NET Runtime
• aspnet-runtime brings the ASP.NET Runtime

This is the case on other Linux distros as well, but often users install the SDK via a 'meta package' that references all three of these core components. If there is any Arch-specific documentation for DevKit we could call this out.

@ComputerMaster1st can you install aspnet-runtime and see if that fixes your scenario when using the latest DevKit?

Executed and appears fine now after that. I only installed dotnet-sdk via pacman as I had no need for ASP related libraries at this time.

[lifengl]

resolved it as a dup of #840