Add workload config command

[dsplaisted]

• Add dotnet workload config command to set the workload update mode
• Fix displaying the workload version in dotnet --info and dotnet workload --version when in workload set mode but no workload set is installed
• Add some initial workload set MSI installation tests

Here's the how the new dotnet workload config command works:

• dotnet workload config --update-mode - Prints the current workload update mode
• dotnet workload config --update-mode workload-set - Switches to workload set update mode
• dotnet workload config --update-mode manifests - Switches to loose manifest update mode

Here's the command-line help:

C:\Users\User>dotnet workload config --help
Description:
  Modify or display workload configuration values.
  To display a value, specify the corresponding command-line option without providing a value.  For example: "dotnet
  workload config --update-mode"

Usage:
  dotnet workload config [options]

Options:
  --update-mode <manifests|workload-set>  Controls whether updates should look for workload sets or the latest version
                                          of each individual manifest.
  -?, -h, --help                          Show command line help.

This replaces the previous syntax, which was dotnet workload update --mode workloadset and dotnet workload update --mode loosemanifest. Note that the previous option was hidden from command-line help, where currently the dotnet workload config command is not hidden.

[baronfel]

For these kinds of config-lookup commands there are generally two patterns:

• NPM-style, where you have a syntax like npm config <get/set/delete/list> <key>[=optional value if the subcommand requires it]
  • Rust's cargo also uses this format
• Git style, where you have git config <key> [value], where the presence of value signals a write instead of a read

I think using one of these forms would be easier for users to understand, because they would have experience in that form from other tools. This form would also scale to a more general dotnet config command in the future, where workload-specific config items would become something like workload.update-mode instead of just update-mode, for example.

To me, we should use one of these forms and use CliArguments to model these inputs. The CliArguments can use the same validation as currently described but make it easier to detect if the argument was even provided (can be controlled via Arity) and the values can be validated once the settings key is known using a validator in much the same way that you have already implemented.

In teams chat today, @marcpopMSFT mentioned that rollback and download link printing could be moved to this config command - I could see that, but I could also see versions like:

• a read-only settings key with a name like package-links or rollback-file
• a version of dotnet workload --info that accepted a flag to print these out, instead of update

I don't see as clear of an answer for that question.

[MiYanni]

@baronfel Correct me if I'm wrong, but doesn't the dotnet CLI have its own style of command structure? Like, a general command format that most of the commands use. I know we don't have rules/regulations against the command format. But I think your comment makes sense in the context of a brand new dotnet config command, where that command would have its own design identity.

In the context of just adding a small set of options for dotnet workload, I recommended we keep it feeling like the style of the rest of the dotnet workload commands. I think that'll make the most sense for this PR. And if we want to eventually make a dotnet config generalized command, we can add the ability to update the workload configuration there and eventually deprecate this usage in dotnet workload.

[baronfel]

We talked today and we're going to keep the existing format in this PR, keeping a more broad treatment of the CLI grammar of a config command for a larger, centralized config effort.

[Forgind]

The _hasUpdateMode check doesn't eliminate this possibility?

[dsplaisted]

No, _hasUpdateMode specifies whether the --update-mode option was specified, but it's possible to specify the option without it's optional argument value, which we use to print the current value.

[Forgind]

.Equals for strings, no?

[dsplaisted]

Fixed (also with invariant ignore case)

[Forgind]

nit: typing - is hard. workloadset?

Also, I thought we were trying to not include "workload set" terminology? Not that I have a better proposal in this case...

[dsplaisted]

I'm pretty sure the guidance I got from @baronfel was to use dashes to separate words. I think that's the style we're going with in the CLI.

[Forgind]

We'd want this to change to echo the version for the current SDK, per our discussion this morning.

[dsplaisted]

I've filed an issue to track the further changes needed: #40005

[MiYanni]

nit private

[dsplaisted]

private would be redundant here. I know it's inconsistent here and probably is throughout our codebase. Do we have a convention we are trying to follow for whether we should include private or not?

[Forgind]

I generally prefer including it...not technically an answer, but it's my preference :)

[MiYanni]

I'm pretty sure explicit access modifiers for fields are the convention in the dotnet org. I'm surprised we don't have that enabled in our editorconfig.

[MiYanni]

You can only get the list of tokens via the Tokens property. The list should be in the order in which they are read. But, that doesn't have a relationship with the CliArguments in any way, unfortunately. You'd have to make custom logic to figure that out.