Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve error message for failed language server startup #73

Closed
tillig opened this issue Feb 8, 2021 · 15 comments
Closed

Improve error message for failed language server startup #73

tillig opened this issue Feb 8, 2021 · 15 comments

Comments

@tillig
Copy link

tillig commented Feb 8, 2021

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
Copy link
Author

tillig commented Feb 8, 2021

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
Copy link
Owner

tintoy commented Feb 8, 2021

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
Copy link
Owner

tintoy commented Feb 8, 2021

And:

const dotnetVersion: string = await dotnet.getVersion();
const canEnableLanguageService: Boolean = dotnetVersion && semver.gte(dotnetVersion, '5.0.0');

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

@tintoy
Copy link
Owner

tintoy commented Feb 8, 2021

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

@tillig
Copy link
Author

tillig commented Feb 8, 2021

dotnet --version

  • In the project directory: 3.1.405
  • Outside the project directory: 5.0.102

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
Copy link
Owner

tintoy commented Feb 8, 2021

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
Copy link
Author

tillig commented Feb 8, 2021

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
Copy link
Author

tillig commented Feb 8, 2021

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
Copy link
Owner

tintoy commented Feb 8, 2021

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 added a commit to tintoy/msbuild-project-tools-server that referenced this issue Feb 8, 2021
We do so 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 in order to ensure that we can target multiple versions of MSBuild, etc.

tintoy/msbuild-project-tools-vscode#73
tintoy added a commit that referenced this issue Feb 8, 2021
We do so 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 in order to ensure that we can target multiple versions of MSBuild, etc.

#73
@tintoy
Copy link
Owner

tintoy commented Feb 8, 2021

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
Copy link
Owner

tintoy commented Feb 9, 2021

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
Copy link
Author

tillig commented Feb 9, 2021

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
Copy link
Owner

tintoy commented Feb 9, 2021

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

@tintoy
Copy link
Owner

tintoy commented Feb 13, 2021

Published v0.3.13 :)

@tintoy tintoy closed this as completed Feb 13, 2021
tintoy added a commit to tintoy/msbuild-project-tools-server that referenced this issue Feb 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants