In https://github.com/dotnet/install-scripts/issues/85 a change was made that allowed for mapping from a user-facing version (e.g. 5.0.100) to a 'final' product version (e.g. 5.0.100-rtm.20471.1) to allow for easier use of the scripts. This would allow users to use the 'friendly' versions of SDKs/Runtimes while still ensuring that they got the most up to date final construction. This check is done as part of Get-Product-Version/get_specific_product_version_url and happens all of the time. The current logic is something like:
Check feed for a productVersion.txt file for the provided logical version - if present use that version
If not present, check the generated download link and parse a version from it - if present use that version
otherwise use the user-passed-in version
This works great for Arcade's use case, but it causes problems when used with another common use case: setting up a parallel set of proxy URLs to use as a custom feed.
To address download failures with the current feeds used by the Install Scripts, the team from https://github.com/dotnet/vscode-dotnet-runtime wanted to set up a series of https://aka.ms links that would emulate the URI structure expected by these scripts, using destination URLs that point to the VS download center. An example of such a link would be https://aka.ms/vscode-dotnet-runtime/Runtime/8.0.0-rc.1.23419.4/dotnet-runtime-8.0.0-rc.1.23419.4-win-x64.zip - the link for the public RC1 stable version of the 8.0.0-rc.1 .NET Runtime. We would only make links for the stable, released public versions of the .NET runtime, asp.net runtime, windows desktop runtime, and SDK. The install scripts would be used with the -AzureFeed https://aka.ms/vscode-dotnet-runtime parameter passed, and this feed was successfully used as the base of the URI construction. However, we do not have a productversion.txt alias defined - and doing so would be a maintenance burden, as the productVersion.txt file contents would need to be updated for every release for every version. Currently, we must provide this file, because not defining the alias results in a 301 redirect to bing.com instead of a 404 - which means the install scripts treat the entire contents of the bing search page as the product version.
Therefore, we'd like the add the following behavior:
A new flag, -SkipProductVersionCheck should be added (--skip-product-version-check in GNU syntax) to the scripts, and if this flag is provided then the scripts should skip checking the productVersion.txt file, relying instead only on the version requested by the user. If that version is incorrect in anyway, the operation is allowed to fail.
In https://github.com/dotnet/install-scripts/issues/85 a change was made that allowed for mapping from a user-facing version (e.g. 5.0.100) to a 'final' product version (e.g. 5.0.100-rtm.20471.1) to allow for easier use of the scripts. This would allow users to use the 'friendly' versions of SDKs/Runtimes while still ensuring that they got the most up to date final construction. This check is done as part of
Get-Product-Version
/get_specific_product_version_url
and happens all of the time. The current logic is something like:This works great for Arcade's use case, but it causes problems when used with another common use case: setting up a parallel set of proxy URLs to use as a custom feed.
To address download failures with the current feeds used by the Install Scripts, the team from https://github.com/dotnet/vscode-dotnet-runtime wanted to set up a series of https://aka.ms links that would emulate the URI structure expected by these scripts, using destination URLs that point to the VS download center. An example of such a link would be https://aka.ms/vscode-dotnet-runtime/Runtime/8.0.0-rc.1.23419.4/dotnet-runtime-8.0.0-rc.1.23419.4-win-x64.zip - the link for the public RC1 stable version of the 8.0.0-rc.1 .NET Runtime. We would only make links for the stable, released public versions of the .NET runtime, asp.net runtime, windows desktop runtime, and SDK. The install scripts would be used with the
-AzureFeed https://aka.ms/vscode-dotnet-runtime
parameter passed, and this feed was successfully used as the base of the URI construction. However, we do not have a productversion.txt alias defined - and doing so would be a maintenance burden, as the productVersion.txt file contents would need to be updated for every release for every version. Currently, we must provide this file, because not defining the alias results in a 301 redirect to bing.com instead of a 404 - which means the install scripts treat the entire contents of the bing search page as the product version.Therefore, we'd like the add the following behavior:
-SkipProductVersionCheck
should be added (--skip-product-version-check
in GNU syntax) to the scripts, and if this flag is provided then the scripts should skip checking the productVersion.txt file, relying instead only on the version requested by the user. If that version is incorrect in anyway, the operation is allowed to fail.