You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Extension errors out with an MSBuild crash due to trying to load an old unsupported vcproj file and predictably failing, instead of ignoring it because its a C++ project.
Should be known that the vcproj files in question are part of a project outside of my control, and their existence in the same folder as the C# project is due to an automated process that will overwrite any changes made. Also should be known that Omnisharp handles this scenario just fine.
Steps to Reproduce
Open a .NET SDK C# project that's in a folder containing an old vcproj.
Note how none of the intellisense stuff works.
Expected Behavior
The C# extension's LSP server should not be trying to load C++ projects.
Actual Behavior
The C# extension's LSP server tries to C++ projects and crashes.
Logs
C# log
Using dotnet configured on PATH
Dotnet path: /home/rstat1/dotnet/dotnet
Activating C# standalone...
waiting for named pipe information from server...
[stdout] {"pipeName":"/tmp/1f6e96be.sock"}
received named pipe information from server
attempting to connect client to server...
client has connected to server
[Info - 3:22:56 PM] [Program] Language server initialized
[Info - 3:22:56 PM] [LanguageServerProjectSystem] Loading /home/rstat1/code/volt2/out/update_engine-bin/jobcache/36be5d2c-673c-47a2-9e13-588339114bc2/Tests/MFC/mfc1/mfc1.sln...
[Error - 3:22:57 PM] [LanguageServerHost] Microsoft.CodeAnalysis.MSBuild.Rpc.RemoteInvocationException: An exception of type Microsoft.Build.Exceptions.InvalidProjectFileException was thrown: The project file "mfc1.vcproj" is in the ".vcproj" file format, which MSBuild no longer supports. Please convert the project by opening it in the Visual Studio IDE or running the conversion tool, or use MSBuild 3.5 or earlier to build it. /home/rstat1/code/volt2/out/update_engine-bin/jobcache/36be5d2c-673c-47a2-9e13-588339114bc2/Tests/MFC/mfc1/mfc1.sln
at Microsoft.CodeAnalysis.MSBuild.Rpc.RpcClient.InvokeCoreAsync(Int32 targetObject, String methodName, List`1 parameters, Type expectedReturnType, CancellationToken cancellationToken) in /_/src/Workspaces/Core/MSBuild/Rpc/RpcClient.cs:line 148
at Microsoft.CodeAnalysis.MSBuild.Rpc.RpcClient.InvokeAsync[T](Int32 targetObject, String methodName, List`1 parameters, CancellationToken cancellationToken) in /_/src/Workspaces/Core/MSBuild/Rpc/RpcClient.cs:line 114
at Microsoft.CodeAnalysis.LanguageServer.HostWorkspace.LanguageServerProjectSystem.OpenSolutionAsync(String solutionFilePath) in /_/src/Features/LanguageServer/Microsoft.CodeAnalysis.LanguageServer/HostWorkspace/LanguageServerProjectSystem.cs:line 109
at Microsoft.CodeAnalysis.LanguageServer.HostWorkspace.LanguageServerProjectSystem.OpenSolutionAsync(String solutionFilePath) in /_/src/Features/LanguageServer/Microsoft.CodeAnalysis.LanguageServer/HostWorkspace/LanguageServerProjectSystem.cs:line 116
at Microsoft.CommonLanguageServerProtocol.Framework.QueueItem`3.StartRequestAsync(TRequestContext context, CancellationToken cancellationToken) in /_/src/Features/LanguageServer/Microsoft.CommonLanguageServerProtocol.Framework/QueueItem.cs:line 136
It doesn't appear there's any public way to bypass that; there's an internal field but that's not settable via a Public API.
jasonmalinowski
changed the title
Extension errors out with an MSBuild crash due to trying to load files it shouldn't
Extension fails to load a solution with a .vcproj in it
Jan 5, 2024
Actually that might fix it only temporarily -- MSBuild is having to roll back the underlying change to use the solution persistence layer due to a few other regressions, so this may not be fixed until we take dotnet/roslyn#77326.
Type: Bug
Issue Description
Extension errors out with an MSBuild crash due to trying to load an old unsupported vcproj file and predictably failing, instead of ignoring it because its a C++ project.
Should be known that the vcproj files in question are part of a project outside of my control, and their existence in the same folder as the C# project is due to an automated process that will overwrite any changes made. Also should be known that Omnisharp handles this scenario just fine.
Steps to Reproduce
Open a .NET SDK C# project that's in a folder containing an old vcproj.
Note how none of the intellisense stuff works.
Expected Behavior
The C# extension's LSP server should not be trying to load C++ projects.
Actual Behavior
The C# extension's LSP server tries to C++ projects and crashes.
Logs
C# log
C# LSP Trace Logs
lsp-trace.txt
Environment information
VSCode version: 1.84.2
C# Extension: 2.12.19
Using OmniSharp: false
Dotnet Information
.NET SDK: Version: 8.0.100 Commit: 57efcf1350 Workload version: 8.0.100-manifests.6c33ef20Runtime Environment:
OS Name: fedora
OS Version: 39
OS Platform: Linux
RID: linux-x64
Base Path: /home/rstat1/dotnet/sdk/8.0.100/
.NET workloads installed:
Workload version: 8.0.100-manifests.6c33ef20
There are no installed workloads to display.
Host:
Version: 8.0.0
Architecture: x64
Commit: 5535e31a71
.NET SDKs installed:
8.0.100-rc.2.23502.2 [/home/rstat1/dotnet/sdk]
8.0.100 [/home/rstat1/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.0-rc.2.23480.2 [/home/rstat1/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.0 [/home/rstat1/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.0-rc.2.23479.6 [/home/rstat1/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.0 [/home/rstat1/dotnet/shared/Microsoft.NETCore.App]
Other architectures found:
None
Environment variables:
DOTNET_ROOT [/home/rstat1/dotnet]
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
Visual Studio Code Extensions
Extension version: 2.12.19
VS Code version: Code 1.84.2 (1a5daa3a0231a0fbba4f14db7ec463cf99d7768e, 2023-11-09T10:50:47.800Z)
OS version: Linux x64 6.5.12-300.fc39.x86_64
Modes:
System Info
canvas_oop_rasterization: disabled_off
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
video_decode: enabled
video_encode: disabled_software
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off
The text was updated successfully, but these errors were encountered: