sdk
sdk copied to clipboard
dotnet
Add download link for specific SDK version
We just published this fancy post on (primarily) downloading runtimes via these helpful links. It occurred to me that we could offer the same fancy links for SDKs.
Here's an example from that post:
The command could not be loaded, possibly because:
* You intended to execute a .NET application:
The application 'build' does not exist.
* You intended to execute a .NET SDK command:
A compatible .NET SDK was not found.
Requested SDK version: 7.0.100-preview.4.22252.9
global.json file: C:\apps\global.json
Installed SDKs:
5.0.408 [C:\Program Files\dotnet\sdk]
Install the [7.0.100-preview.4.22252.9] .NET SDK or update [C:\apps\global.json] to match an installed SDK.
Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found
Wouldn't the following be better (and symmetric with runtimes)?
The command could not be loaded, possibly because:
* You intended to execute a .NET application:
The application 'build' does not exist.
* You intended to execute a .NET SDK command:
A compatible .NET SDK was not found.
Requested SDK version: 7.0.100-preview.4.22252.9
global.json file: C:\apps\global.json
Installed SDKs:
5.0.408 [C:\Program Files\dotnet\sdk]
Install the [7.0.100-preview.4.22252.9] .NET SDK or update [C:\apps\global.json] to match an installed SDK.
Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found
To install missing SDK, download:
https://aka.ms/dotnet/missing-sdk?version=7.0.0-preview.4.22252.9&arch=x64&rid=win10-x64
@baronfel @elinor-fung @mairaw
Nice. Once we have a link, adding the text on the host side once should be quick.
There'd probably also be a variation where we don't have a specific requested version (the user has no SDK installed), so we'd just have the arch and rid for query parameters.
In that case, we'd have the version of the host, like we do in the "no .net" apphost case. Right?
Yep, we we'd have the version of the host (dotnet). We could definitely include a host_version parameter. I'm not sure if it makes more sense for the link to redirect to try to match the host version or just always point at latest when there is no SDK installed though (since, unlike for 'no .net' apphost, we can use the latest SDK when there's no specific requested SDK version).
I think it would make sense to pass the info and then we can figure out the right policy on the server side later. Keep our options open.
I'd love to see this! If there's a known format for the download links, I could even see a place for them in the output of tools like dotnet sdk check:
14:31:54 ❯ dotnet sdk check
.NET SDKs:
Version Status
----------------------------------------------------------
3.1.420 Up to date.
5.0.214 .NET 5.0 is out of support.
5.0.303 .NET 5.0 is out of support.
5.0.408 .NET 5.0 is out of support.
6.0.106 Up to date.
6.0.202 Patch 6.0.203 is available.
6.0.203 Up to date.
6.0.300 Patch 6.0.301 is available.
6.0.301 Up to date.
6.0.400-preview.22316.6 Up to date.
7.0.100-preview.6.22316.8 Up to date.
.NET Runtimes:
Name Version Status
------------------------------------------------------------------------------------------
Microsoft.AspNetCore.App 3.1.25 Patch 3.1.26 is available.
Microsoft.NETCore.App 3.1.25 Patch 3.1.26 is available.
Microsoft.WindowsDesktop.App 3.1.25 Patch 3.1.26 is available.
Microsoft.AspNetCore.App 3.1.26 Up to date.
Microsoft.NETCore.App 3.1.26 Up to date.
Microsoft.WindowsDesktop.App 3.1.26 Up to date.
Microsoft.AspNetCore.App 5.0.9 .NET 5.0 is out of support.
Microsoft.NETCore.App 5.0.9 .NET 5.0 is out of support.
Microsoft.WindowsDesktop.App 5.0.9 .NET 5.0 is out of support.
Microsoft.AspNetCore.App 5.0.17 .NET 5.0 is out of support.
Microsoft.NETCore.App 5.0.17 .NET 5.0 is out of support.
Microsoft.WindowsDesktop.App 5.0.17 .NET 5.0 is out of support.
Microsoft.NETCore.App 6.0.0-rc.2.21480.5 Patch 6.0.6 is available.
Microsoft.WindowsDesktop.App 6.0.0-rc.2.21501.6 Patch 6.0.6 is available.
Microsoft.NETCore.App 6.0.2 Patch 6.0.6 is available.
Microsoft.WindowsDesktop.App 6.0.2 Patch 6.0.6 is available.
Microsoft.AspNetCore.App 6.0.3 Patch 6.0.6 is available.
Microsoft.NETCore.App 6.0.3 Patch 6.0.6 is available.
Microsoft.WindowsDesktop.App 6.0.3 Patch 6.0.6 is available.
Microsoft.NETCore.App 6.0.4 Patch 6.0.6 is available.
Microsoft.WindowsDesktop.App 6.0.4 Patch 6.0.6 is available.
Microsoft.AspNetCore.App 6.0.5 Patch 6.0.6 is available.
Microsoft.NETCore.App 6.0.5 Patch 6.0.6 is available.
Microsoft.WindowsDesktop.App 6.0.5 Patch 6.0.6 is available.
Microsoft.AspNetCore.App 6.0.6 Up to date.
Microsoft.NETCore.App 6.0.6 Up to date.
Microsoft.WindowsDesktop.App 6.0.6 Up to date.
Microsoft.WindowsDesktop.App 7.0.0-preview.6.22311.2 Up to date.
Microsoft.NETCore.App 7.0.0-preview.6.22312.1 Up to date.
Microsoft.AspNetCore.App 7.0.0-preview.6.22312.2 Up to date.
The latest versions of .NET can be installed from https://aka.ms/dotnet-core-download. For more information about .NET lifecycles, see https://aka.ms/dotnet-core-support.
Imagine all of those Patch X.Y.Z is available texts being VT-enabled hyperlinks to get the latest versions.
That's be sweet!
Yes, there is a known format. Here's is one of the links:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=7.0.0-preview.4.22251.1&arch=x64&rid=win10-x64
We'd probably want to create a different one for this scenario so we know its a different scenario, like:
https://aka.ms/dotnet/check/get?framework=Microsoft.AspNetCore.App&framework_version=7.0.0-preview.4.22251.1&arch=x64&rid=win10-x64
If you want to make that happen (in the tool), I can do the rest.
FYI: I'm trying to switch all of links to a new scheme. Instead of https://aka.ms/dotnet-core-download, we can instead go with https://aka.ms/dotnet/download. We've been slowly converting with - to / and dropped core. It looks better.
Let's decide what we want to do and then I'll make both links at the same time.
@richlander @baronfel should we choose a link / format to get something into 7?
I think the suggestions from previous comments are:
For the host (in dotnet/runtime repo) when SDK is not found: https://aka.ms/dotnet/missing-sdk With query parameters:
- version
- Only if a specific version of the SDK was requested
- Maybe sdk_version? It would match the other *_version names
- arch
- rid
- host_version
For the SDK check command: https://aka.ms/dotnet/check/get With query parameters:
- framework
- framework_version
- arch
- rid
old issue never done. Did we want to take another look at it or delay for now?
