installer
installer copied to clipboard
dotnet
Please provide patch-agnostic URLs for runtime downloads
When you distribute a framework-dependent app, it's necessary to give the users a URL to download the runtime if they don't have it already. The best link for this currently appears to be https://dotnet.microsoft.com/download/dotnet/5.0/runtime, but it confronts users with several choices, only one of which is right. Along with this URL, I have to say "make sure you click the x64 button under the desktop apps section." This is clumsy to have to explain, and for some kinds of users, error-prone.
So why not give the end users a link to the direct download of the correct runtime, e.g. https://dotnet.microsoft.com/download/dotnet/thank-you/runtime-desktop-5.0.7-windows-x64-installer? The problem is that this pins a specific patch version of the runtime. I don't want that because they will be installing a version that is missing security updates. Also, thank-you in the URL feels vaguely undesirable but I can't put my finger on why. Ideally the URL could also be short.
Proposal
A URL that seems ideal to me would be something like https://dot.net/download/runtime/desktop/x64/5.0. It would provide the latest 5.0.x x64 desktop runtime. If the version part was 5 instead of 5.0, it would provide the latest 5.x.x x64 desktop runtime. Maybe it would be nice if it showed a landing page and also immediately started a download. Maybe for the ease of building web installers, an additional /direct URL part could cause a direct download. But the experience needs to be nice for non-technical folks who don't know the terms x64 vs Arm64 or console vs desktop.
doesn't look like we are getting out of this "GUIDs everywhere" trend... e.g. node.js has a no-brainier distribution list https://nodejs.org/dist/ since pre-v1, and several tools (including nvm) enjoy that simple logical structuring which inherently provide uniqueness by something called "path"... so if someone is going to DDoS they are gonna do that anyway on any public link and you should protect THAT from happening without employing obscurities like horrible GUIDs, it doesn't help here anyway, only makes URLs look awful.
This was actually already implemented by https://github.com/dotnet/arcade/issues/5757
E.g. to get the latest 5.0 released build you can use:
- https://aka.ms/dotnet/5.0/dotnet-runtime-win-x64.exe (runtime)
- https://aka.ms/dotnet/5.0/windowsdesktop-runtime-win-x64.exe (Windows Desktop runtime)
- https://aka.ms/dotnet/5.0/aspnetcore-runtime-win-x64.exe (ASP.NET Core runtime)
- https://aka.ms/dotnet/5.0/dotnet-sdk-win-x64.exe (SDK)
It also works for 6.0 preview builds which you can get with:
- https://aka.ms/dotnet/6.0/preview/dotnet-runtime-win-x64.exe (runtime)
- https://aka.ms/dotnet/6.0/preview/windowsdesktop-runtime-win-x64.exe (Windows Desktop runtime)
- https://aka.ms/dotnet/6.0/preview/aspnetcore-runtime-win-x64.exe (ASP.NET Core runtime)
- https://aka.ms/dotnet/6.0/preview/dotnet-sdk-win-x64.exe (SDK)
@akoeplinger That looks fantastic! Does the runtime-win link contain the desktop runtime?
No that one only includes the base shared framework, the desktop one would be https://aka.ms/dotnet/5.0/windowsdesktop-runtime-win-x64.exe. I've updated the links above.
I think that answers my question, and I have a followup question. How can people generally discover these URLs without opening a new issue in this repo to find out about them?
(Also: besides the regular runtime and the desktop runtime, there's the web runtime according to the screenshot at the top of this thread. The links for all three runtime downloads should probably be advertised together.)
Hmm good question.
@mmitche what's the plan for advertising these new aka.ms links? should we post an announcement to dotnet/announcements?
Hmm good question.
@mmitche what's the plan for advertising these new aka.ms links? should we post an announcement to dotnet/announcements?
Yeah, I think we should. /cc @adiaaida @bekir-ozturk @richlander. I'm unlikely to get to this prior to being OOF though.
Oh sweet, do these links work for the other OS/platforms the installers are offered on (like MacOS x64, linux, etc)?
I know of some people that might be in a situation where they make a standalone application that "acts" as an installer to their main program (they made it from scratch using .NET MAUI) and so then they want it to download only the latest versions of the runtime (like jnm2 pointed out) for that particular OS (and cpu bitness) before proceeding to install their program.
(And yes people like me do that just so we can use HttpClient to download the runtimes within the installer so the actual application bundled inside would not need to be self contained itself)
Yes they work for other OSes too, e.g.
- https://aka.ms/dotnet/5.0/dotnet-runtime-osx-x64.pkg
- https://aka.ms/dotnet/5.0/dotnet-runtime-linux-x64.tar.gz
- https://aka.ms/dotnet/6.0/preview/dotnet-sdk-osx-x64.pkg
- https://aka.ms/dotnet/6.0/daily/dotnet-sdk-osx-x64.pkg
- https://aka.ms/dotnet/6.0/preview/dotnet-sdk-linux-x64.tar.gz
- https://aka.ms/dotnet/6.0/daily/dotnet-sdk-linux-x64.tar.gz
For .NET 6 public preview releases and daily ones.
Edit: Thanks to this issue, I have since created an github action (https://github.com/Elskom/setup-latest-dotnet) that basically invokes the .NET Install scripts to install with the daily quality releases in GitHub actions. 👌
- https://aka.ms/dotnet/6.0/preview/dotnet-sdk-osx-x64.pkg
- https://aka.ms/dotnet/6.0/daily/dotnet-sdk-osx-x64.pkg
- https://aka.ms/dotnet/6.0/preview/dotnet-sdk-linux-x64.tar.gz
- https://aka.ms/dotnet/6.0/daily/dotnet-sdk-linux-x64.tar.gz
For .NET 6 public preview releases and daily ones.
Edit: Thanks to this issue, I have since created an github action (https://github.com/Elskom/setup-latest-dotnet) that basically invokes the .NET Install scripts to install with the daily quality releases in GitHub actions. 👌
You'll need a slight tweak to that since we have SDK bands that follow VS releases and so there will eventually be multiple SDKs :
- https://aka.ms/dotnet/6.0.1xx/preview/dotnet-sdk-osx-x64.pkg
- https://aka.ms/dotnet/6.0.1xx/daily/dotnet-sdk-osx-x64.pkg
- https://aka.ms/dotnet/6.0.1xx/preview/dotnet-sdk-linux-x64.tar.gz
- https://aka.ms/dotnet/6.0.1xx/daily/dotnet-sdk-linux-x64.tar.gz
The preview quality band should be signed and point to the latest preview. The daily will not be signed and will point to the last build of the sdk (daily is a bit of a misnomer. It's more like "rolling").
Note that for runtimes, the 6.0 is correct, since runtimes->sdk is a 1:many relationship.
- https://aka.ms/dotnet/6.0/preview/dotnet-sdk-osx-x64.pkg
- https://aka.ms/dotnet/6.0/daily/dotnet-sdk-osx-x64.pkg
- https://aka.ms/dotnet/6.0/preview/dotnet-sdk-linux-x64.tar.gz
- https://aka.ms/dotnet/6.0/daily/dotnet-sdk-linux-x64.tar.gz
For .NET 6 public preview releases and daily ones. Edit: Thanks to this issue, I have since created an github action (https://github.com/Elskom/setup-latest-dotnet) that basically invokes the .NET Install scripts to install with the daily quality releases in GitHub actions. 👌
You'll need a slight tweak to that since we have SDK bands that follow VS releases and so there will eventually be multiple SDKs :
* https://aka.ms/dotnet/6.0.1xx/preview/dotnet-sdk-osx-x64.pkg * https://aka.ms/dotnet/6.0.1xx/daily/dotnet-sdk-osx-x64.pkg * https://aka.ms/dotnet/6.0.1xx/preview/dotnet-sdk-linux-x64.tar.gz * https://aka.ms/dotnet/6.0.1xx/daily/dotnet-sdk-linux-x64.tar.gzThe preview quality band should be signed and point to the latest preview. The daily will not be signed and will point to the last build of the sdk (daily is a bit of a misnomer. It's more like "rolling").
So I cant just keep it as 6.0 to have it auto select the latest band being developed for that specific major and minor version of the sdk itself?
We are looking at doing something like this via the dotnet.ms.com site that is focused on latest releases (preview or stable). We will share a short spec when we have it.
@mairaw
Anyone know when https://aka.ms/dotnet/7.0/daily/dotnet-sdk-osx-x64.pkg would work to download daily builds of the .NET 7 SDK (when that feed will be made available)?
For now, we are not creating patch agnostic sdk links. You'll need to use https://aka.ms/dotnet/7.0.1xx/daily/dotnet-sdk-osx-x64.pkg (which does currently work).
We should do those, too, please. For a lot of users, the SDK bands don't matter. For example, for Docker, we expose the two-part versions for both runtimes and SDK as the primary currency.
We should do those, too, please. For a lot of users, the SDK bands don't matter. For example, for Docker, we expose the two-part versions for both runtimes and SDK as the primary currency.
Do we document what our bands mean somewhere? The SDK bands do sometimes matter, as they can also map to new tooling versions that could have meaningful impacts on users projects. I'm okay with having patch agnostic URLs, but I think the nitty details matter.
See what we do with Docker ... https://hub.docker.com/_/microsoft-dotnet-sdk
We get a ton of usage there and this model seems to have worked. Separately, we're going to create a page at dotnet/core (release notes) that documents the .NET SDK to VS relationship. That's been missing.
We also have multiple sdk patch bands being published at the same time. For example, we are still actively releasing both 5.0.4xx and 5.0.2xx, as well as having 6.0.1xx and 6.0.1xx-rc1. Which of these should correspond to the patch agnostic url? This question is part of why we limited these urls to the patch versions. Additionally, how do we push that forward with newer patch bands? Do we have to shift the version with every new sdk version?
i can understand wanting whatever main is pointing to to also get a patch agnostic link, and that I think we can work on, but once we get to released versions of the sdk, and multiple side by side versions being released, we need to be a lot more careful about what we call “the” sdk for that major version band
@adiaaida I think it's relatively easy for the daily links. We'd have to alter the aka ms generation to generate multiple links, then update the channel configurations in PublishingConstants so that the latest SDK band for a major version always gets the agnostic aka.ms link too.
I'm not sure what that looks like for signed generation in the staging pipeline or in the final release pipelines.
The final release pipeline (so preview and ga links) already produce aka.ms links for sdk without the patch. I think if we did this for daily links, signed/validated would likely just get it for free.
Created https://github.com/dotnet/arcade-services/issues/2444 to track this in arcade for us.
Is there clear documentation on the available links? I was completely unaware this existed and this would be of great benefit for installers to direct users to the correct latest patch version as frequently they pick the wrong one despite clear instructions.
Also is there a link for the ASP.NET Runtime Hosting Bundle ? This is critical.
Also is there a link for the ASP.NET Runtime Hosting Bundle ? This is critical.
https://aka.ms/dotnet/6.0/aspnetcore-runtime-win-x64.exe I guessed it based on diffing the final URLs for the desktop runtime download and the ASP.NET Core runtime download.
I wish there were easy "copy to clipboard" buttons for these URLs in discoverable places on the download pages.
It's still not the hosting bundle. The hosting bundle is bitness agnostic (probably bundles both) with IIS extra bits apparently. It's what MS recommend on the download page for Windows.
But yeah, it's guessable. Given the version download is dotnet-hosting-6.0.6-win.exe for latest...
https://aka.ms/dotnet/6.0/dotnet-hosting-win.exe
Seems to work.
In reference to the original request: I think the runtime download page (https://dotnet.microsoft.com/en-us/download/dotnet/8.0/runtime) is ok for technical users if given a few additional hints on what to download. It doesn't contain patch agnostic links but will always point you to the latest patch.
But how do you even navigate to this website? It isn't mentioned anywhere, you just have to know it exists. Or am I just unable to find it?
The whole .NET website more or less forces you to download the SDK. Which is fine, since it contains the runtime, but one could argue that the runtime will be required more often than the SDK so I don't see the point of hiding the runtime. I know there are ways to bundle the runtime alongside the app and maybe that's the strategy here but when taking file size and security into account, installing a separate runtime on the target computer is a good choice. There should at least be a link in the website navigation that gets you to the runtime download. Or if that is out of the question, I would like to know why.
But how do you even navigate to this website?
https://dot.net, click "Downloads" and then to runtime page.
or use this url template: https://aka.ms/dotnet/{version}/dotnet-{product}-{os}-{arch}.{ext}
ex:
sdk w. runtime: https://aka.ms/dotnet/8.0/dotnet-sdk-linux-x64.tar.gz
runtime (only): https://aka.ms/dotnet/8.0/dotnet-runtime-win-arm64.zip
https://dot.net, click "Downloads" and then to runtime page.
Sorry, @kasperk81 but that is not the case for me. I tried Firefox, I tried Edge, i searched the HTML, when I navigate to Downloads (https://dotnet.microsoft.com/en-us/download to be specific), runtime is not even mentioned. It all points towards the SDK or the "All downloads" page (https://dotnet.microsoft.com/en-us/download/dotnet/8.0), where you can also download the runtime, but I simply cannot find a link to this page: https://dotnet.microsoft.com/en-us/download/dotnet/8.0/runtime
Maybe the content is targeted towards different countries / audiences? Please post a screenshot if possible.