josephwoodward
Discover and/or modify global.json
I’ve been bitten by global.json, not realising it was specified somewhere in the working directory hierarchy, so adding discoverability would be useful; i.e. a subcommand that enumerates all known config files and maybe goes into more detail showing their content.
Also, when tinkering with an open source project, I often take another approach, which is to edit any global.json to match what I have installed, since I prune my installed sdks to the minimum set required for the latest versions.
We have a pending feature (here) that will enumerate directories in the same manner as the dotnet cli. More verbose output would be useful here.
From what I understand, at some point Microsoft will make it say we can say "at least this SDK version" in global.json, which will fully fix your second point, the problem with changing it manually is that you don't know if the OSS repo you are dealing with really needs that version, or just pinned a convenient version, or latest at that point in time.
From my experience it tends to be whatever version was available at that point in time. Besides, it’s easy to revert and install the original version if bumping it breaks something.
So would your suggestion be to allow for this tool to say "It looks like you have a later version of this SDK, use that instead of downloading the exact version?", and yes would rewrite the file to the nearest version that's higher and copy the old version to global.json.bak?
My current workflow for that sort of thing is:
rm global.json
dotnet new globaljson
which will default to the latest SDK you dotnet cli finds, but isn't as intelligent as what is described above.
That would be a great start - apply latest initially and add intelligence for better major.minor compatibility later.
If a global dotnet tool can have config then I’d add options around the above; e.g. don’t generate a backup file (when using source control).
Without wanting to alter the default behaviour of dotnet install-sdk, I suppose one option would be to have flag to allow you to apply a later version if you have it. But at this point I'd question whether it would be better off just deleting the global.json file as if someone isn't interested in using the version pinned then the file's existence is kinda redundant.
That's where I'm at with this one too, you typically want to do one of two things, ignore the project.json (then delete it), or adhere to it and acquire the necessary sdk, this tool helps with the latter.