Add dotnetup --info, dotnetup --version, dotnetup list #52717
Add dotnetup --info, dotnetup --version, dotnetup list #52717nagilson merged 25 commits intodotnet:release/dnupfrom
dotnetup --info, dotnetup --version, dotnetup list #52717Conversation
adds architecture, sha, and version for debugging customer issues more easily
… than sdk install now
nagilson
changed the title
dotnetup --info, dotnetup --version, dotnetup list` dotnetup --info, dotnetup --version, dotnetup list
This reverts commit 8ff8bf4.
Separate console IO out because disposing concurrent spectre console writers causes failures
may not actually be the right thing to do here, checking..
|
Edit: Ah, I changed copilot instructions which are in the sdk code root. |
Co-authored-by: Copilot <[email protected]>
This allows --info to have options like --json where it cant do that if its a bool. A bit hacky and it doesn't display on the root command but I think that's acceptable.
dsplaisted
left a comment
dsplaisted
left a comment
There was a problem hiding this comment.
Looks good. For things like using Spectre.Console to do the formatting, feel free to file an issue for that if you don't want to hold up this PR.
| <NoWarn>$(NoWarn);CS8002</NoWarn> | ||
|
|
||
| <!-- dotnetup versioning --> | ||
| <VersionPrefix>0.0.1</VersionPrefix> |
There was a problem hiding this comment.
Microsoft.Dotnet.Installation.csproj also has version information in it. Could we unify these into a Directory.Build.props file or something?
We would probably want to use 0.1.1 as the version so that we don't publish out of order package versions.
There was a problem hiding this comment.
I've bumped the version, good idea! Do you mean to unify the 2 versions or move the version handling for both into one space? I think we can track that elsewhere.
There was a problem hiding this comment.
We should define the version in one place and have it affect both the NuGet package and the version of dotnetup. I think Directory.Build.props in the src\Installer directory is probably the place to do that.
There was a problem hiding this comment.
Gotchu! #52795
To make things simpler to review and not block other work, filed this here.
| InstallComponent.Runtime => "Microsoft.NETCore.App", | ||
| InstallComponent.ASPNETCore => "Microsoft.AspNetCore.App", | ||
| InstallComponent.WindowsDesktop => "Microsoft.WindowsDesktop.App", |
There was a problem hiding this comment.
I would probably use something like the following for human-readable names:
- .NET Core Runtime
- ASP.NET Runtime
- .NET Windows Desktop Runtime
@baronfel might know if there are better / official names.
There was a problem hiding this comment.
I could go either way on this but lean against this change - dotnet --list-runtimes and dotnet --info uses the more verbose text and I wanted to maintain parity.
There was a problem hiding this comment.
Those are the official names, but users almost never directly interact with the 'full' names. It's all implicit, driving by the use of the various MSBuild SDK's they use in their projects. Human-readable is IMO the way to go here, but I wouldn't use .NET Core Runtime, ASP.NET Runtime, or .NET Windows Desktop Runtime for anything around user input. We should have shorter, punchier names for them for use in flags/options, and these names are what I think we should be surfacing.
Proposal:
- Microsoft.NETCore.App => dotnet (runtime)
- Microsoft.AspNetCore.App => aspnet (runtime)
- Microsoft.WindowsDesktop.App => windowsdesktop (runtime)
There was a problem hiding this comment.
I've done this below but kept the json as full names as they inform the directories of the installs and I can think of a lot of code that relies on those values 🤔
src/Resolvers/Microsoft.NET.Sdk.WorkloadManifestReader/Strings.resx
Outdated
Show resolved
Hide resolved
|
@nagilson Is this ready to merge? I think we can ignore the dotnet-sdk-public-ci failures since they don't apply to this branch. Do you want to /ba-g it? Or I can also force merge it if needed. |
|
/ba-g failures are known issues with the sdk repo |
3 participants
Resolves #50613
Please see the added documentation specs for options provided.
A machine readable format via
--jsonis added alongside a human readable version.