Skip to content

Add path to global.json in SDK resolution error message when it's available #25823

@baronfel

Description

@baronfel

SDK resolution error messages currently look like this:

Unable to locate the .NET SDK version '{0}' as specified by global.json, please check that the specified version is installed.

This is helpful, but doesn't tell the user which global.json is impacting the resolution. This is often fairly straightforward to find out (since global.json is heirarchical, it must be at or above the working directory of the process invocation), but can be outside of what the user expects.

We should incorporate the path to the global.json into this message when it is available for every message that mentions global.json, for the following named message strings (as possible) (list valid as of this commit):

  • MSBuildSDKDirectoryNotFound
  • MSBuildSmallerThanMinimumVersion
  • NETCoreSDKSmallerThanMinimumRequestedVersion
  • NETCoreSDKSmallerThanMinimumVersionRequiredByVisualStudio
  • UnableToLocateNETCoreSdk
  • GlobalJsonResolutionFailed
  • GlobalJsonResolutionFailedSpecificVersion

Here are the docs for the native API:

//   result
//      Callback invoked to return values. It can be invoked more
//      than once. String values passed are valid only for the
//      duration of a call.
//
//      If resolution succeeds, then result will be invoked with
//      resolved_sdk_dir key and the value will hold the path to
//      the resolved SDK directory.
//
//      If global.json is used, then result will be invoked with
//      global_json_path key and the value will hold the path
//      to global.json. If there was no global.json found,
//      or the contents of global.json did not impact resolution
//      (e.g. no version specified), then result will not be
//      invoked with global_json_path key. This will occur for
//      both resolution success and failure.
//
//      If a specific version is requested (via global.json), then
//      result will be invoked with requested_version key and the
//      value will hold the requested version. This will occur for
//      both resolution success and failure.

Per these docs, if we have a 'requested version' in our result, then a global.json was present, so we should always have the path. Therefore it should be safe to have two variants of most of these messages:

  • one without version/global.json path information
  • one with version/global.json path information

Originally posted by @baronfel in #25733 (comment)

This is related to #24480

Metadata

Metadata

Assignees

Labels

Area-CLIcli-uxIssues and PRs that deal with the UX of the CLI (exit codes, log output, verbs/options, and so on)good first issueIssues that would be a good fit for someone new to the repository. Narrow in scope, well-defined.

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions