Diagnostics: Determine the URI for single-file tool downloads

[josalem]

As we prepare to ship the tools as single-file exes, we need to decide the URI these are downloaded from. We are currently planning to create aka.ms links that will always point at the newest versions of the tools on the Microsoft downloads CDN. The URIs should include the tool name and the runtime identifier (RID).

Here are a couple options:

• aka.ms/dotnet-trace.linux-x64
• aka.ms/dotnet-trace/linux-x64
• aka.ms/dotnetTraceLinuxX64

CC @noahfalk @shirhatti @hoyosjs

[noahfalk]

Of the three options above I'd take "aka.ms/dotnet-trace/linux-x64". @kevingosse also chatted with me earlier and probably has some opinions here. He suggested we could do something like https://aka.ms/getvsdbgsh where the script helps you pick the rid. I don't think this needs to be an either/or - I assume the cost of supporting both is pretty cheap? The rid version seems nice because it doesn't require extra steps to mark the script as executable and then run it, but for someone who doesn't know or remember what rid they need I could still see it being pretty helpful.

cc @chrisnas @pieroxy

[noahfalk]

@josalem did you confirm that the content-disposition header will let us have links that don't end with dotnet-trace, but by default the file will be named dotnet-trace when it is downloaded?

[josalem]

@hoyosjs and I are still looking into whether the CDN allows us to specify that header per file on upload.

[hoyosjs]

@noahfalk I can't test that right now, but considering the AKA link is separate from the download center link, the vanity link shouldn't have any impact on it.

[sywhang]

+1 on aka.ms/dotnet-trace/linux-x64 as long as the CDN lets us specify file name : )

[chrisnas]

Choices 1 or 2 look good to me.
Should we expect the same kind of url for the other CLI tools (dotnet-dump, ...)?
Would it be possible to have the same zipped/tar for the diagnostics family like for SysInternals?
https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite (BTW they use choice 2 for each urls)

Is there any need to provide versioned links?
Since the tool relies on the CLR implementation (to answer to the eventpipe-based protocol), the last version might no be compatible with a previous supported version of the CLR. For example, I'm thinking about adding a command to list the EventSource (i.e. providers for dotnet-trace) so that the user would not have to guess which one is available.

[kevingosse]

aka.ms/dotnet-trace/linux-x64 works for me!

[noahfalk]

Should we expect the same kind of url for the other CLI tools (dotnet-dump, ...)?

Yep : )

Would it be possible to have the same zipped/tar for the diagnostics family like for SysInternals?

Probably, but I don't want to commit to a 3rd way of packaging them up before we've got this individual app approach done and in your hands : )

Is there any need to provide versioned links?

Ideally there shouldn't be a need, the tools are designed to be back compatible. In practice that aka.ms link has to redirect somewhere and I suspect behind the scenes it will be versioned.

[josalem]

closed via - #1544 #1709