tintoy / msbuild-project-tools-vscode

VS Code extension for MSBuild intellisense (including PackageReference completion).
MIT License
82 stars 16 forks source link

Improve error message for failed language server startup #73

Closed tillig closed 3 years ago

tillig commented 3 years ago

As of about 10 days ago the language server needs .NET SDK 5.0.102 installed in order to start, but you can target any SDK you want in your project. This took effect in release 0.3.12 of the VS Code plugin.

Unfortunately, from an end user perspective, the error message is slightly confusing. First VS Code pops up a note saying the language server couldn't start and you should check the logs. Then in the logs you get a message like this:

Error: Command failed: "/usr/local/share/dotnet/dotnet" "/Users/tillig/.vscode/extensions/tintoy.msbuild-project-tools-0.3.12/out/language-server/MSBuildProjectTools.LanguageServer.Host.dll" --probe System.Exception: Cannot locate MSBuild engine for .NET SDK v5.0 (5.0.102 <= SDK version <= 5.0.999). Found version(s): [5.0.100]. at MSBuildProjectTools.LanguageServer.Program.DiscoverMSBuildEngine() in C:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer\Program.cs:line 198 at MSBuildProjectTools.LanguageServer.Program.Main() in C:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer\Program.cs:line 51

It was confusing to me both why it was trying to locate that version of .NET 5 (I have 5.0.100, it couldn't use that?) and also why it was looking for .NET 5 at all since the project where I discovered this was targeting .NET Core 3.1. After looking into how the project build tools work and seeing the changes, now I get it, but I'm curious if the error message could be improved with some sort of "call to action" explaining what's up.

Like, instead of just an exception and that's it, maybe a longer message saying what the readme says - you need to have .NET 5.0.102 (or compatible) installed, but you can target whatever you want... and here's a link to go download the latest SDK.

Or maybe the error message has a URL to an FAQ over here on GitHub that explains what it means and why.

Point being, it would be nice to have a slightly more helpful message that doesn't require research into how the language server works, if possible.

tillig commented 3 years ago

Unclear if it's related, but after installing .NET 5.0.102, in that same project I now see:

Cannot enable the MSBuild language service ('3.1.405' is not a supported version of the .NET Core runtime).

My global.json specifies

{
  "sdk": {
    "rollForward": "latestFeature",
    "version": "3.1.405"
  }
}

dotnet --list-sdks yields:

2.1.811 [/usr/local/share/dotnet/sdk]
3.1.405 [/usr/local/share/dotnet/sdk]
5.0.100 [/usr/local/share/dotnet/sdk]
5.0.102 [/usr/local/share/dotnet/sdk]

dotnet --list-runtimes yields:

Microsoft.AspNetCore.All 2.1.23 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.23 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.11 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.23 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.11 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

I see the SDK is there, but, no, there's no Microsoft.NETCore.App 3.1.405 and there shouldn't be - 3.1.405 SDK ships with 3.1.11 runtime.

I'm not sure what I should do at this point to re-enable the MSBuild language service.

tintoy commented 3 years ago

Yeah this is what I was afraid of when it came to upgrading to 5.x, the different SDK/runtime/MSBuild versions do not play nicely together 😢

The MSBuildLocator API was meant to handle correctly locating the version of MSBuild for the target SDK but if you’re seeing that message then it is returning unexpected results. I’ll take a look at this after work this evening (am in Australia so UTC+11 here) and see what I can do.

I agree the error message could definitely be improved. I’ll have a think about how to do that (your suggestions are a great starting point!)...

tintoy commented 3 years ago

The code in question:

https://github.com/tintoy/msbuild-project-tools-server/blob/b9d60385d3d8c146460ebc46eff903b4ed9ad8ba/src/LanguageServer/Program.cs#L173-L201

tintoy commented 3 years ago

And:

https://github.com/tintoy/msbuild-project-tools-vscode/blob/345579cff727935dc22466a82b36cb2d08959843/src/extension/extension.ts#L51-L52

Perhaps we should only check the runtime version if the extension won’t load...

tintoy commented 3 years ago

What does dotnet --version return? And if you run it from outside the project directory?

tillig commented 3 years ago

dotnet --version

I haven't used MSBuildLocator but it definitely seems more geared toward Visual Studio than .NET Core; I'm curious if they might have some insight on it.

tintoy commented 3 years ago

msbuild-project-tools-0.3.13.vsix.zip

Can you try this package and see if it works for you? It now uses the host version, rather than the current runtime version (i.e. ignores global.json when deciding if the language server itself can be started, since this depends purely on the host version).

tillig commented 3 years ago

I first uninstalled the one from the online gallery, then installed the VSIX. That went smoothly. I opened up the project and a notification "Initializing MSBuild project tools..." came up. I went to the Output window and noticed there were two output windows for "MSBuild Project Tools."

Two output panels

In the first one, I saw the output:

Starting MSBuild language service...

In the second one I saw:

System.Exception: Cannot locate MSBuild engine for .NET SDK v5.0 (5.0.102 <= SDK version <= 5.0.999). Found version(s): [3.1.405].
   at MSBuildProjectTools.LanguageServer.Program.DiscoverMSBuildEngine() in C:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer\Program.cs:line 198
   at MSBuildProjectTools.LanguageServer.Program.Main() in C:\Development\github\tintoy\msbuild-project-tools-vscode\lib\server\src\LanguageServer\Program.cs:line 51
[Error - 1:04:28 PM] Connection to server got closed. Server will not be restarted.

3.1.405 is the SDK version I'm targeting with the global.json as noted above, but it seems like it's confused.

A full exit/restart/re-open project yielded the same error with the same two-output-window issue, so it doesn't appear to be tied to the uninstall/reinstall or anything.

tillig commented 3 years ago

Hmmm. The two output window thing is still there after reinstalling the version from the marketplace. Perhaps it's always been like that? I also see the exact same error message, so... hmmm.

tintoy commented 3 years ago

Yeah I think maybe that second check is unnecessary. It’s just the runtime (host) version we care about. I’ll see if I can modify it this afternoon so it doesn’t care what SDK version it is using but logs the SDK version on startup.

tintoy commented 3 years ago

Ok, so I've improved the logic for this by making a distinction between runtime (host) and SDK versions, using the runtime version as the target for the extension / language server itself, and using the SDK version to find an appropriate version of MSBuild.

We will probably need to move the MSBuild stuff out to a separate process at some point, though, in order to ensure that we can target multiple versions of the .NET SDK / MSBuild (otherwise we'll keep running into these cross-version problems).

Will try to get you another package to try later today 🙂

tintoy commented 3 years ago

msbuild-project-tools-0.3.13.vsix.zip

Ok, can you give this one a try? You'll need to remove the old extension by hand before installing it (same version number).

tillig commented 3 years ago

That version totally starts up and runs.

Starting MSBuild language service...
MSBuild language service is running.

Verified I can hover over an <ItemGroup> and see how it evaluates, so it's definitely going. 🎉

tintoy commented 3 years ago

Ok I’ll just add some logging for the MSBuild version and publish a new package :)

tintoy commented 3 years ago

Published v0.3.13 :)