Core: Well Known/Stable Links should be provided for downloading released versions of all tools.

[tannergooding]

Issue

Currently, the tools are hidden by a fwlink, such as https://go.microsoft.com/fwlink/?linkid=841683, which represents the Window x64 tools for RC4.

Even after resolving the fwlink the resolved URL is not human parseable and is not consistent between releases. The above fwlink resolve to https://download.microsoft.com/download/B/4/6/B4678511-01F4-4F97-902B-0E58A985932A/dotnet-dev-win-x64.1.0.0-rc4-004771.zip, for example.

Proposal

The tools should instead be provided at a well known stable address so they can be downloaded dynamically by build tools that are dependent on a specific version.

Example

For example, in order to take a dependency on a specific version of NuGet, one can define a build variable such as:
$NUGET_VERSION = "3.5.0"

It can then be accessed from a well known URL:
https://dist.nuget.org/win-x86-commandline/v$NUGET_VERSION/NuGet.exe

If I then decide to take a dependency on a new version of NuGet, I merely need to change the definition of $NUGET_VERSION. For example, to move forward to 4.0.0-rc4, I would change this to be $NUGET_VERSION = "4.0.0-rc4".

In a similar manner, the dotnet/core tools should all be provided at a stable/well-known address, such as: https://downloads.dot.net/dotnet-dev/v1.0.0-rc4-004771/win-x64.zip and https://downloads.dot.net/dotnet-dev/v1.0.0-rc4-004771/ubuntu-x64.zip.

This allows users to write manageable (and readable) build scripts that are easily configurable to download specific versions of the dotnet tools for use in their build systems.

If URLs were provided in the above manner, then changing from rc3 to rc4 is as simple as changing the target version from 1.0.0-rc3-004530 to 1.0.0-rc4-004771.

[leecow]

Thanks for the proposal @tannergooding. We're having similar discussions around here and share the desire for a more transparent, if not predictable, download url scheme. I don't know if we will get it ironed out by the next round, which will coincide with the final release of VS2017, but it will be as soon as we can work it out.

[Petermarcu]

We actually do have stable links. We just need to document how to construct them. We have a script here: https://github.com/dotnet/cli/tree/rel/1.0.0/scripts/obtain that we use in our own builds.

What we're currently thinking to do is to host that script at a well known location, then build machines can grab the script they need, call it with the right arguments for the version they want to run on and the script will do all the work.

@tannergooding , thoughts?

@piotrpMSFT was just telling me something broke them for acquiring the runtime from core-setup builds but we should fix that. @gkhanna79 FYI

[gkhanna79]

was just telling me something broke them for acquiring the runtime from core-setup builds but we should fix that

The scripts above are hardcoded to 1.0.x layout in the blob store, which had changed in 1.1.0 for better organization but CLI never targeted 1.1.0 (until probably now) and thus, never saw it.

The key issue is that https://github.com/dotnet/cli/tree/rel/1.0.0/scripts/obtain needs to become resilient to various .NET Core releases. I am already on an offline thread with Peter to get this fixed.

[tannergooding]

@Petermarcu, while something like those scripts would work, I think a 500 line powershell or a 700 line shell script is really a lot more complicated then it needs to be 😄.

Those scripts, which are just for downloading dotnet cli are larger than the scripts we currently use for Build, Restore, and Test in some of our repositories.

What I want is the ability to give three things and call a string format function to download the bits I need:

• Version
• Operating System (Windows, Ubuntu, Mac, etc -- possibly including the OS Version, if required. Such as: ubuntu.14.04)
• Target Platform (x86, x64, ARM, etc)

That is simple, self explanatory, and can be done in very few lines of shell script on any platform.

[Petermarcu]

Yup, I agree on the complexity comment. I think you also need to be able to specify if you want the SDK or just the runtime.

[richlander]

This is a good issue.This is a good 2.0 issue, for easy runtime and sdk installation. Should this issue be ported to the cli repo?

/cc @blackdwarf

[tannergooding]

@richlander, was this ported elsewhere?

[richlander]

No. I shouldn't have closed this.

[Petermarcu]

@richlander , we should probably get this moved into a product repo where it can get tracked as real work.

On a side note, there is a pretty cool community project that solves some of this: https://github.com/faniereynders/dotnet-sdk-helpers

[leecow]

@tannergooding - with the 2.0 release we've produced and will maintain a comprehensive release metadata file. Have a look at let me know if this will help with your use case and any suggestions for improvements.

https://github.com/dotnet/core/blob/master/release-notes/releases.json

[tannergooding]

@leecow, this still isn't as "simple" as I (or some others) would probably like it because, for official RTM or Preview releases, this still requires parsing some external data file in order to determine what to download.

At this point, the azure blob URL is the closest to what I would think is "ideal". That is, a URL where all I need to replace is the version and it will continue downloading the correct thing. The improvement that could be made, would be that a https://dot.net URL be provided the forwards to the azure blob URL.

NuGet is a perfect example of "easy to use" and "easy to update". They provide a single sub-domain on their site for all downloads (https://dist.nuget.org) and easy to parse URLs.

If I want the latest NuGet, I can always grab from: https://dist.nuget.org/win-x86-commandline/latest/nuget.exe
If I want a specific version, I can always grab from: https://dist.nuget.org/win-x86-commandline/v{version}/nuget.exe (example: v4.3.0 is https://dist.nuget.org/win-x86-commandline/v4.3.0/nuget.exe).

This allows me to write scripts where I can have a string containing the basic URL format and replace just the version and expect it to continue working.

# Top of file, all defaults for variable inputs
$nuget_version = "2.0.0"

# Code

$nuget_url = "https://dist.nuget.org/win-x86-commandline/v$nuget_version/nuget.exe"
DownloadFile($nuget_url)

# More Code

Now, when a new version of NuGet comes out, I replace a few characters at the top of my script and I'm done. I don't have to download any intermediate files, I don't have to parse the data, I don't have to have a dependency on JSON.NET, I don't have to use anything that isn't basic Bash or Powershell commands, etc.

[Petermarcu]

should have done this a long time ago but I moved this into the 2.1 milestone in the cli repo. https://github.com/dotnet/cli/issues/7769