dotnet / install-scripts Goto Github PK

License: MIT License

Batchfile 0.15% Shell 30.91% PowerShell 42.08% CMake 3.54% C# 23.33%

install-scripts's Introduction

This repo is the central place for dotnet install and install dotnet preview scripts.

Please be advised that the project is currently in maintenance mode. This implies that we are focusing on addressing high-priority bugs and providing assistance with any issues that may arise. During this phase, no new features or significant improvements are anticipated.

For more information about the usage of dotnet install, see: https://learn.microsoft.com/dotnet/core/tools/dotnet-install-script

To download the latest stable versions of dotnet install, go to:

Bash (Linux/macOS): https://dot.net/v1/dotnet-install.sh
PowerShell (Windows): https://dot.net/v1/dotnet-install.ps1

Information about the usage of install dotnet preview is provided here: https://github.com/dotnet/core/blob/main/release-notes/7.0/install-linux.md#install-using-debrpm-packages

The latest stable versions of install dotnet preview is available here:

https://dotnetcli.blob.core.windows.net/dotnet/release/install-preview/install-dotnet-preview.sh

install-scripts's People

Stargazers

Watchers

install-scripts's Issues

dotnet-install.ps1 too verbose

Steps to reproduce

I see this when cloning and building dotnet/corefx.

It prints:

dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
dotnet-install: Extracting zip from https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
dotnet-install: Adding to current process PATH: "F:\gh\corefx\.dotnet\". Note: This change will not be visible if PowerShell was run as a child process.
dotnet-install: Installation finished

The third line confuses me:

dotnet-install: Adding to current process PATH: "F:\gh\corefx\.dotnet\". Note: This change will not be visible if PowerShell was run as a child process.

I'm not running PowerShell, and don't know about PATH. Maybe the script invoker cares, but as a user I don't. Shouldn't this message me silenced unless the caller uses a "-Verbose" or similar switch?

Expected behavior

Actual behavior

Environment data

dotnet --info output:

Add support for aka.ms links for dotnet-install

Add support for the aka.ms links to dotnet-install so that we can remove the copy to latest in various repositories. dotnet-install should, either as the primary method, or a backup, attempt to use the aka.ms links as a method of getting at the latest installers for a specific channel.

aka.ms links have been designed to place the link to a specific blob under a predictable url:

aka.ms/dotnet/net5/dev/Sdk/dotnet-sdk-win-x86.exe
aka.ms/dotnet/<channel>/Sdk/dotnet-sdk-win-x86.exe

The version information has been removed.

Currently, the one hiccup here is that we don't have a version file to know whether the latest version may already be installed. This should be implemented with: dotnet/installer#5554 (similar entries exist in windowsdesktop, runtime, and aspnetcore). This version file could simply be published alongside the rest of the blobs.

Build stability: Consider detection of incomplete .NET SDK download and retry

@dotnet-mc-bot commented on Mon Oct 08 2018

There were a set of failures during this build. Here is a summary of these:

https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_build?_a=summary&buildId=2097028
- Agent: DDVSOLINUXAGE009
- Error log: dotnet_install: Error: Extraction failed...

@jcagme, @markwilkie

@MattGal commented on Thu Oct 11 2018

This is an interesting one, so I'll move it to CLI to see if they want to investigate it.

Basically the script gets the download it was doing cancelled at around 13% complete, but then tries to untar the resulting download, with predictable results:

2018-10-08T10:45:06.1631996Z Using code from: /data/agent/_work/306/s
2018-10-08T10:45:07.1421050Z + /opt/code/scripts/obtain/dotnet-install.sh --version 2.1.300 --install-dir /opt/code/.dotnet_stage0/x64 --architecture x64
2018-10-08T10:45:07.1688717Z dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.300/dotnet-sdk-2.1.300-linux-musl-x64.tar.gz
2018-10-08T10:45:07.2550436Z Connecting to dotnetcli.azureedge.net (72.21.81.200:443)
2018-10-08T10:45:07.8691124Z 
2018-10-08T10:45:08.0778587Z dotnet.wjsTY1NCx      13% |****                           | 21631k  0:00:06 ETA
2018-10-08T10:45:08.0942417Z dotnet-install: Extracting zip from https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.300/dotnet-sdk-2.1.300-linux-musl-x64.tar.gz
2018-10-08T10:45:09.6490445Z tar: unexpected end of file
2018-10-08T10:45:09.6492222Z tar: short read
2018-10-08T10:45:09.9809933Z dotnet_install: Error: Extraction failed
2018-10-08T10:45:10.6676847Z /bin/bash failed with return code: 1

It seems an obvious candidate for error detection and possibly retry.

dotnet-install.ps1 installs locally even when same version is already installed globally

Steps to reproduce

On a machine that already has 2.2.101 SDK installed
.\dotnet-install.ps1 -Version 2.2.101

Expected behavior

Do nothing.

Maybe provide a -Force parameter so that only when that is given, do you still install the version

Actual behavior

Version is installed into c:\users\USERNAME\AppData\Local\Microsoft\dotnet, even if it was already installed in C:\Program Files\dotnet\sdk

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.2.101
 Commit:    236713b0b7

Runtime Environment:
 OS Name:     Windows
 OS Version:  6.3.9600
 OS Platform: Windows
 RID:         win81-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.2.101\

Host (useful for support):
  Version: 2.2.0
  Commit:  1249f08fed

.NET Core SDKs installed:
  1.0.0-preview2-003156 [C:\Program Files\dotnet\sdk]
  2.1.200 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.302 [C:\Program Files\dotnet\sdk]
  2.1.401 [C:\Program Files\dotnet\sdk]
  2.1.403 [C:\Program Files\dotnet\sdk]
  2.2.100 [C:\Program Files\dotnet\sdk]
  2.2.101 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Review documentation for when the install scripts are to be used

See dotnet/docs#18715 for the detailed discussion of the problem the current behavior causes to users.

Add install script option to install dependencies

Per @richlander :

Open question ... Should the fine folks working on / using the GitHub Actions Runner use the install script to install .NET dependencies?

https://github.com/actions/runner/blob/master/docs/start/envlinux.md

Repeated invocations of dotnet-install.sh will fill TMP directory

Issue moved from dotnet/sdk#11858

Please respond to @MattGal.

From @MattGal on Tuesday, June 2, 2020 5:43:10 PM

See https://github.com/dotnet/sdk/blob/master/scripts/obtain/dotnet-install.sh#L822

We had all the test machines run out of disk space overnight from just running too many tests. (in the case I investigated it was about 900 tests on one machine leading to 21 GB of SDKs in the TMP folder).

Thoughts on how to fix:

At a minimum, when the job is done successfully the zip_path file should be deleted if it exists regardless of content
Could consider also a more distinct temp file name and cleaning up someDistinctDotNettyName.* in TMP every time.

Powershell Install script is not signed

Originally from

@jozefizso on Friday, December 13, 2019 2:28:43 PM

Why is the PowerShell script unsigned? How do we know we are running a legitimate script when it's downloaded from internet on each build?

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a2e484a9-5e0c-eb3e-1413-7b507c4fa07d
Version Independent ID: 5bc7caa5-f1c2-d7d5-fe02-80c65cca9672
Content: dotnet-install scripts - .NET Core CLI
Content Source: docs/core/tools/dotnet-install-script.md
Product: dotnet-core
Technology: dotnet-cli
GitHub Login: @mairaw
Microsoft Alias: mairaw

Copied from original issue: dotnet/docs#16242

dotnet-install fails with Exception calling invoke with 0 arguments

I am trying to install dotnet core on Windows Server 2016 by following instructions in:
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script
and it failed.

PS C:\scripts> ./dotnet-install.ps1 -Channel 2.1 -Version latest
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.804/dotnet-sdk-2.1.804-win-x64.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.804/dotnet-sdk-2.1.804-win-x64.zip
dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.804/dotnet-dev-win-x64.2.1.804.z
ip
Exception calling "Invoke" with "0" argument(s): "Failed to download
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.804/dotnet-dev-win-x64.2.1.804.zip."
At C:\opt\framework\dotnet-install.ps1:110 char:20

```
        return $ScriptBlock.Invoke()
```
```
               ~~~~~~~~~~~~~~~~~~~~~
```
- CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordException
- FullyQualifiedErrorId : RuntimeException

PS C:\scripts> ./dotnet-install.ps1 --channel LTS
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/LTS/dotnet-sdk-LTS-win-x64.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/LTS/dotnet-sdk-LTS-win-x64.zip
dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/LTS/dotnet-dev-win-x64.LTS.zip
Exception calling "Invoke" with "0" argument(s): "Failed to download
https://dotnetcli.azureedge.net/dotnet/Sdk/LTS/dotnet-dev-win-x64.LTS.zip."
At C:\opt\framework\dotnet-install.ps1:110 char:20

```
        return $ScriptBlock.Invoke()
```
```
               ~~~~~~~~~~~~~~~~~~~~~
```
- CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordException
- FullyQualifiedErrorId : RuntimeException

Download is slower in scripts than in browser

My ISP has been having trouble with download speeds from abroad recently, and I found myself in a position where I can't build the repo because the SDK download fails for during the build script initialisation.

For example:

C:\Users\gotos\source\repos\runtime>build -subset clr+libs -runtimeConfiguration release
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.5.20251.2/dotnet-sdk-5.0.100-preview.5.20251.2-win-x64.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.5.20251.2/dotnet-sdk-5.0.100-preview.5.20251.2-win-x64.zip
dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.5.20251.2/dotnet-dev-win-x64.5.0.100-preview.5.20251.2.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.5.20251.2/dotnet-dev-win-x64.5.0.100-preview.5.20251.2.zip
Failed to install dotnet runtime '' from public location.
Some builds failed:
        Configuration: Debug, Architecture: x64

The odd thing is, that downloading the SDK through a web browser is faster when compared to the time taken when the script is able to successfully download the script.

This might be related with dotnet/runtime#33510 (comment):

I also noticed that the initial download done by dotnet-install.ps1 (~180MB) takes about 8 minutes. While downloading the same file via browser takes about 2 minutes. So I tried it with Invoke-WebRequest with $ProgressPreference = 'SilentlyContinue' which gave me around 1.5 minutes. So I think there might be a room for improvement in the install script.

In addition, It appears that the script sometimes get stuck downloading nothing (checked through taskmgr), and won't respond to Ctrl+C if I try to cancel the process during the download. The script simply gets stuck after logging dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.5.20251.2/dotnet-sdk-5.0.100-preview.5.20251.2-win-x64.zip and it takes hours for that to fail and return control.

Lastly, The "legacy link" it attempts to download from after failing to download from the primary source, e.g. https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.5.20251.2/dotnet-dev-win-x64.5.0.100-preview.5.20251.2.zip, returns status code 404 saying The specified blob does not exist. RequestId:b2657274-301e-0002-4869-28aa31000000 Time:2020-05-12T14:31:06.5790236Z.

It is possible that this issue belongs in other repo (dotnet/sdk?) but I will leave it here for now as I am not entirely clear if that is the case.

SH doesn't correctly grab global.json sdk version

https://dotnet.microsoft.com/download/dotnet-core/scripts/v1/dotnet-install.sh when run as bash ./dotnet-install.sh --jsonfile ./global.json grabs everything in sdk after version instead of only grabbing the sdk.version value.

Example of global.json:

{
  "sdk": {
    "version": "3.1",
    "allowPrerelease": false,
    "rollForward": "latestPatch"
  }
}

error:

dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1allowPrerelease:falserollForward:latestPatch/dotnet-sdk-3.1allowPrerelease:falserollForward:latestPatch-linux-x64.tar.gz
curl: (22) The requested URL returned error: 404 Not Found
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1allowPrerelease:falserollForward:latestPatch/dotnet-sdk-3.1allowPrerelease:falserollForward:latestPatch-linux-x64.tar.gz
dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1allowPrerelease:falserollForward:latestPatch/dotnet-dev-centos-x64.3.1allowPrerelease:falserollForward:latestPatch.tar.gz
curl: (22) The requested URL returned error: 404 Not Found
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1allowPrerelease:falserollForward:latestPatch/dotnet-dev-centos-x64.3.1allowPrerelease:falserollForward:latestPatch.tar.gz
dotnet_install: Error: Could not find/download: `.NET Core SDK` with version = 3.1allowPrerelease:falserollForward:latestPatch
dotnet_install: Error: Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a2e484a9-5e0c-eb3e-1413-7b507c4fa07d
Version Independent ID: 5bc7caa5-f1c2-d7d5-fe02-80c65cca9672
Content: dotnet-install scripts - .NET Core CLI
Content Source: docs/core/tools/dotnet-install-script.md
Product: dotnet-core
Technology: dotnet-cli
GitHub Login: @tdykstra
Microsoft Alias: tdykstra

dotnet-install.ps1 doesn't handle global.json that contains comments

This is an issue when using dotnet-install.ps1 to install the dotnet SDK. When running restore or building, the comment is handled just fine.

Offending Line:
https://github.com/dotnet/sdk/blob/dc6a9b177858767908fa68cb6677adca278ac1ec/scripts/obtain/dotnet-install.ps1#L314

Possible Fix:
((Get-Content .\global.json) -replace '^\s*//.*' | ConvertFrom-Json).sdk.version //This removes comments during parsing

example global.json:

{
  "sdk": {
    // Need to use a particular version to ensure consistency across machines no matter what SDK versions they have installed.
    "version": "3.1.201"
  }
}

Scripts deadlock during resource downloading (sometimes)

On issue dotnet/sdk#11621, @Gnbrkm41 wrote:

It appears that the script sometimes get stuck downloading nothing (checked through taskmgr), and won't respond to Ctrl+C if I try to cancel the process during the download. The script simply gets stuck after logging dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.5.20251.2/dotnet-sdk-5.0.100-preview.5.20251.2-win-x64.zip and it takes hours for that to fail and return control.

which seems to be happening when internet is slow.

SDK version parsing from global.json is not working on macOS

This is the same problem as in dotnet/sdk#12339.

Running install script dotnet-install.sh with jsonfile argument works on macOS only when sdk section has a single property version. When sdk section has multiple properties, for example,

"sdk": {
    "version":  "5.0.100-preview.6.20310.4",
    "allowPrerelease": true,
    "rollForward": "major"
  }

a version is detected as 5.0.100-preview.6.20310.4allowPrerelease:truerollForward:major.
Also, in a case when version is not the first property in sdk a version can not be detected returning an error dotnet_install: Error: Unable to find the SDK:version node in `global.json` .

SH installs wrong architecture on ARM64 host, ARM32 OS

Issue Description

get_machine_architecture contains the following:

https://github.com/microsoft/azure-pipelines-tasks/blob/08914a70defbdbe73b2bb87e8d0663bdbeb248e0/Tasks/UseDotNetV2/externals/get-os-distro.sh#L159-L178

This is... fundamentally not how uname should be used.

uname refers to the profile of the running kernel, not the executing environment. It can be a 100% mismatch, and that's valid and fine. The .NET Core environment which gets installed needs to match the executing environment, not the kernel.

Some examples:

(xenial-armhf)root@xam-softiron-16:/# uname -a
Linux xam-softiron-16 4.15.0-50-generic dotnet/cli#54~16.04.1-Ubuntu SMP Wed May 8 15:55:41 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
(xenial-armhf)root@xam-softiron-16:/# file /bin/bash
/bin/bash: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib, for GNU/Linux 3.2.0, BuildID[sha1]=9a214a5bbfe98a862fd835fdcbfa1d9f8dabff0e, stripped

root@breakfast:/# uname -a
Linux breakfast 4.15.0-50-generic dotnet/cli#54-Ubuntu SMP Mon May 6 18:46:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
root@breakfast:/# file /bin/bash 
/bin/bash: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib, for GNU/Linux 3.2.0, BuildID[sha1]=d3d60e9d8193746d270cd74bcb2f5742ffc65d48, stripped

In both these cases, these are 64-bit kernels with 32-bit executing environments. There is no guarantee that 64-bit libraries are available to execute 64-bit code, and it is a 32-bit .NET Core which should be installed.

armv7l is not the only valid uname which requires a 32-bit .NET Core. 32-bit compatibility kernel profile on 64-bit ARM kernels will show armv8l:

$ uname -a
Linux xam-softiron-15 4.15.0-50-generic dotnet/cli#54~16.04.1-Ubuntu SMP Wed May 8 15:55:41 UTC 2019 armv8l armv8l armv8l GNU/Linux

ref: microsoft/azure-pipelines-tasks#10439

Add a warning, explaining the correct use case for the scripts

Addressing the issue here: dotnet/docs#18715

Some users perceive the install scripts as a replacement to the other installers (like msi): they expect to be able to access the installed runtime after powershell exits. This attempt fails since necessary environment variables will only work within the same powershell that installed the sdk (or scripts run from the same powershell).

Add a warning so that people who wants to install a runtime to run apps should use other installation options.

Use releases-index.json as source for "channels"

This file contains a list of latest stable releases: https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json.

It would be nice if dotnet-install.ps1 could use this to automatically interpret -Channel into the exact version it should download.

Proposed usage:

./dotnet-install.ps1 -Channel 2.1 -Runtime aspnetcore

How this might work:
The script could download https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json. -Channel 2.1 maps to this entry:

{
    "channel-version": "2.1",
	// .... other stuff ...
    "releases.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/2.1/releases.json"
}

Next, fetch https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/2.1/releases.json and read the data from this file to find the appropriate file.

Consider hardening scripts/obtain/dotnet-install.sh against connection reset issues / fix legacy download

@dotnet-mc-bot commented on Tue Oct 23 2018

There were a set of failures during this build. Here is a summary of these:

https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_build?_a=summary&buildId=2145365
- Agent: DDVSOLINUXAGE004
- Error log: curl: (22) The requested URL returned error: 404 Not Found...
https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_build?_a=summary&buildId=2145363
- Agent: DDVSOLINUXAGE002
- Error log: curl: (22) The requested URL returned error: 404 Not Found...
https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_build?_a=summary&buildId=2145368
- Agent: DDVSOLINUXAGE006
- Error log: �[39;49m�[36m 1>�[39;49m�[39;49m�[31m/opt/code/build/Test.targets(0,0): error MSB6006: "dotnet" exited with code 134. [/opt/code/build.proj]...

@jcagme, @markwilkie

@MattGal commented on Tue Oct 23 2018

This problem has been seen in several places this morning (it would seem the dotnetcli storage account and/or CDN has a rough night) but in this specific case the code that's doing the dotnet-install stuff is from https://github.com/dotnet/cli/blob/release/2.1.4xx/scripts/obtain/dotnet-install.sh which would be the only place to fix it via retry logic (note that curl --retry seems to have difficulty with certain types of failures and not perform retries in this and "TCP Connection Reset by Peer" states.

Clarify that 404 at "downloading legacy link" in dotnet-install.sh is usually expected

When builds fail with issues like this, there's a huge red herring:

Trying to run 'curl https://dot.net/v1/dotnet-install.sh -sSL --retry 10 --create-dirs -o /__w/1/s/.dotnet/dotnet-install.sh' for maximum of 5 attempts.
Ran 'curl https://dot.net/v1/dotnet-install.sh -sSL --retry 10 --create-dirs -o /__w/1/s/.dotnet/dotnet-install.sh' successfully.
dotnet_install: Warning: Unable to locate zlib. Probable prerequisite missing; install zlib.

dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.3.20168.11/dotnet-sdk-5.0.100-preview.3.20168.11-linux-x64.tar.gz
curl: (56) GnuTLS recv error (-9): A TLS packet with unexpected length was received.

dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.3.20168.11/dotnet-sdk-5.0.100-preview.3.20168.11-linux-x64.tar.gz

dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.3.20168.11/dotnet-dev-ubuntu.16.04-x64.5.0.100-preview.3.20168.11.tar.gz
curl: (22) The requested URL returned error: 404 Not Found

dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.3.20168.11/dotnet-dev-ubuntu.16.04-x64.5.0.100-preview.3.20168.11.tar.gz

dotnet_install: Error: Could not find/download: `.NET Core SDK` with version = 5.0.100-preview.3.20168.11
dotnet_install: Error: Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support

The error here is curl: (56) GnuTLS recv error (-9). But, people see the 404 for the legacy download and sometimes miss the main problem, think the 404 might be a related problem, or that they have a secondary problem to look into also.

The message should clarify that the legacy download link is not a backup. (This is a typical interpretation.)

Or, can we remove the legacy fallback? What versions actually use it (are they EOL)?

Add Signing validation to build pipeline

Background: ps1 script is now signed after the changes here: #14

Problem: Arcade automatically validates signed packages, but not other files. Therefore, signature of the script is not validated as part of the build pipeline.

What we need to do:

Edit build definition to utilize arcade SignCheck: https://github.com/dotnet/arcade/tree/master/src/SignCheck
Builds should fail and generated artifacts shouldn't be published to blob storage if signing validation fails.

Useful links: https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.Arcade.Sdk/tools/SdkTasks/SigningValidation.proj#L48
https://github.com/dotnet/arcade/blob/master/eng/common/templates/post-build/post-build.yml#L200

dotnet-install.sh dependency checks are incorrect

When I build the coreclr component, I get dotnet_install: Warning: Unable to locate zlib. Probable prerequisite missing; install zlib. soon after the script starts running, even though I do have zlib installed and the build finishes without any error.

This also appears to be happening in CI builds as well, as can be seen here: https://dev.azure.com/dnceng/public/_build/results?buildId=614751&view=logs&j=2336a351-be5a-5f79-bbfa-f7a178b0fa04&t=faf0c5b5-f158-5102-6aff-48775dc0e8ed&l=24

It seemed to not cause any problems, but it's odd to see the warning there.

PS1 failed without error diagnosis

For this issue the error is simply the following

https://dev.azure.com/dnceng/public/_build/results?buildId=492107&view=logs&j=1f7f0ae9-6d8b-5300-18e4-8627865be549&t=a4594482-09b1-5607-9af7-3db5e61ee1a3

2020-01-21T20:01:12.6940988Z [2020/01/21 20:01:12][INFO] DotNet Install Path: 'D:\a\1\s\tools\dotnet\x64'
2020-01-21T20:01:12.6941667Z [2020/01/21 20:01:12][INFO] Downloading https://dot.net/v1/dotnet-install.ps1
2020-01-21T20:01:14.8182491Z [2020/01/21 20:01:14][INFO] $ pushd "D:\a\1\s"
2020-01-21T20:01:14.8183653Z [2020/01/21 20:01:14][INFO] $ powershell.exe -NoProfile -ExecutionPolicy Bypass D:\a\1\s\tools\dotnet\x64\dotnet-install.ps1 -InstallDir D:\a\1\s\tools\dotnet\x64 -Architecture x64 -Channel release/3.1.2xx
2020-01-21T20:01:16.1690996Z [2020/01/21 20:01:16][INFO] dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.200-preview-014917/dotnet-sdk-3.1.200-preview-014917-win-x64.zip
2020-01-21T20:01:17.4609587Z [2020/01/21 20:01:17][INFO] dotnet-install: Extracting zip from https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.200-preview-014917/dotnet-sdk-3.1.200-preview-014917-win-x64.zip
2020-01-21T20:01:30.7387155Z [2020/01/21 20:01:30][INFO] ".NET Core SDK" with version = 3.1.200-preview-014917 failed to install with an unknown error.
2020-01-21T20:01:30.7388687Z [2020/01/21 20:01:30][INFO] At D:\a\1\s\tools\dotnet\x64\dotnet-install.ps1:678 char:5
2020-01-21T20:01:30.7389370Z [2020/01/21 20:01:30][INFO] +     throw "`"$assetName`" with version = $SpecificVersion failed to i ...
2020-01-21T20:01:30.7389836Z [2020/01/21 20:01:30][INFO] +     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2020-01-21T20:01:30.7390375Z [2020/01/21 20:01:30][INFO]     + CategoryInfo          : OperationStopped: (".NET Core SDK"... unknown error.:String) [], RuntimeException
2020-01-21T20:01:30.7390856Z [2020/01/21 20:01:30][INFO]     + FullyQualifiedErrorId : ".NET Core SDK" with version = 3.1.200-preview-014917 failed to install with an unknown
2020-01-21T20:01:30.7391357Z [2020/01/21 20:01:30][INFO]    error.
2020-01-21T20:01:30.7391761Z [2020/01/21 20:01:30][INFO] 
2020-01-21T20:01:30.8569932Z [2020/01/21 20:01:30][ERROR] Process exited with status 1
2020-01-21T20:01:30.8575593Z [2020/01/21 20:01:30][INFO] $ popd

Cannot install 1.0.5 & 1.1.2 runtimes

How do you build this? I've created a new Ubuntu 18.04 VM (which can successfully build the dotnet/runtime repo) and tried running build.sh as outlined in the repo docs, however it immediately fails:

dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Runtime/1.0.5/dotnet-runtime-1.0.5-linux-x64.tar.gz
curl: (22) The requested URL returned error: 404
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Runtime/1.0.5/dotnet-runtime-1.0.5-linux-x64.tar.gz
dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Runtime/1.0.5/dotnet-ubuntu.18.04-x64.1.0.5.tar.gz
curl: (22) The requested URL returned error: 404
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Runtime/1.0.5/dotnet-ubuntu.18.04-x64.1.0.5.tar.gz
dotnet_install: Error: Could not find/download: `.NET Core Runtime` with version = 1.0.5

dotnet-install.sh Fails When global.json Contains rollForward=latestMajor

When I add the rollForward property to my global.json file like so:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "latestMajor"
  }
}

My MacOS build fails with the following error:

dotnet-install:(B Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.100rollForward:latestMajor/dotnet-sdk-3.1.100rollForward:latestMajor-osx-x64.tar.gz
curl: (22) The requested URL returned error: 404 
dotnet-install:(B Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.100rollForward:latestMajor/dotnet-sdk-3.1.100rollForward:latestMajor-osx-x64.tar.gz
dotnet-install:(B Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.100rollForward:latestMajor/dotnet-dev-osx-x64.3.1.100rollForward:latestMajor.tar.gz
curl: (22) The requested URL returned error: 404 
dotnet-install:(B Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.100rollForward:latestMajor/dotnet-dev-osx-x64.3.1.100rollForward:latestMajor.tar.gz
dotnet_install: Error: Could not find/download: `.NET Core SDK` with version = 3.1.100rollForward:latestMajor(B
dotnet_install: Error: Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support(B
Command exited with code 1

My Ubuntu 18.04 build fails with the following error:

dotnet_install: Warning: Unable to locate zlib. Probable prerequisite missing; install zlib.�(B
dotnet-install:(B Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.100rollForward:latestMajor/dotnet-sdk-3.1.100rollForward:latestMajor-linux-x64.tar.gz
curl: (22) The requested URL returned error: 404 
dotnet-install:(B Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.100rollForward:latestMajor/dotnet-sdk-3.1.100rollForward:latestMajor-linux-x64.tar.gz
dotnet-install:(B Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.100rollForward:latestMajor/dotnet-dev-ubuntu.18.04-x64.3.1.100rollForward:latestMajor.tar.gz
curl: (22) The requested URL returned error: 404 
dotnet-install:(B Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.100rollForward:latestMajor/dotnet-dev-ubuntu.18.04-x64.3.1.100rollForward:latestMajor.tar.gz
dotnet_install: Error: Could not find/download: `.NET Core SDK` with version = 3.1.100rollForward:latestMajor(B
dotnet_install: Error: Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support(B
Command exited with code 1

You can find my AppVeyor build here and GitHub PR here. My full PowerShell Core script:

if ($isLinux) {
  sudo apt update
  sudo apt install -y zlib1g apt-transport-https
} else {
  brew update
  brew install mono
  brew install mono-libgdiplus
  $env:TERM = 'xterm'
}

Invoke-WebRequest "https://dot.net/v1/dotnet-install.sh" -OutFile "./dotnet-install.sh";
chmod u+x dotnet-install.sh
./dotnet-install.sh --jsonfile global.json

dotnet-install.ps1 not installing latest 2.1 aspnetcore

Currently both
https://dotnetcli.blob.core.windows.net/dotnet/aspnetcore/Runtime/2.1/latest.version
and
https://dotnetcli.blob.core.windows.net/dotnet/aspnetcore/Runtime/2.1/latest.version

Return -

8d09403118ca5d3d972b599b50f942be359a9a49
2.1.18

As the latest version, however according to the downloads site
https://dotnet.microsoft.com/download/dotnet-core

2.1.19 is the latest since 2020-06-09

It does not appear that the AzureFeed or UncachedFeed are up to date

Script fails to access the feed if TLS1.2 is not enabled

https://twitter.com/dotMorten/status/1246109315624095744

dotnet-install.ps1 doesn't have a flag to stop dotnet.exe before updating

I'm running the script on a server (Azure Service Fabric cluster + VMSS) while production services are running) but getting an error:

The process cannot access the file 'C:\Program Files\dotnet\dotnet.exe' because it is being used by another process.

I wish there were a flag like -Force or -Stop that would stop all dotnet.exe before updating it. However the doc doesn't say there is one:

dotnet-install.ps1 [-Architecture <ARCHITECTURE>] [-AzureFeed]
    [-Channel <CHANNEL>] [-DryRun] [-FeedCredential]
    [-InstallDir <DIRECTORY>] [-JSonFile <JSONFILE>]
    [-NoCdn] [-NoPath] [-ProxyAddress]
    [-ProxyUseDefaultCredentials] [-Runtime <RUNTIME>]
    [-SkipNonVersionedFiles] [-UncachedFeed] [-Verbose]
    [-Version <VERSION>]

Use global.json from current directory automatically

It would be great if I could do dotnet-install.sh like nvm use where the current directory is consulted and installs that specific version specified in global.json. I know theres the --jsonfile option, but the file name is required.

Can install script be an single exe?

Just an idea. Now we have the single and trimmed exe in 3.0. We could rewrite the install script to C# and publish it as win32, mac and Linux generic self contained binaries.

C# is easier to maintain than 2 scripting language. And it can also reduce the platform dependency.

dotnet-install script causes shell to exit

Steps to reproduce

Create an Ubuntu 16.04 VM in Azure
Run the following:

wget https://dot.net/v1/dotnet-install.sh
chmod 700 dotnet-install.sh
source dotnet-install.sh --shared-runtime --version 1.1.2

Expected behavior

A message is displayed about missing dependencies (libuwind8 etc)

Actual behavior

It just exits my shell. Unless its a subshell, this results in my whole terminal window just closing.

Workaround

Install all the dependencies first, with sudo apt-get install curl libunwind8 gettext apt-transport-https

32 bit .NET Being Installed on 64 Bit Machine

When a 32 bit command prompt is opened, the build downloads 32 bit dotnet even though the machine is a 64 bit. On a 32 bit command prompt the architecture is stored in two variables
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64
where as a 64 bit command prompt is stored in just one variable.
PROCESSOR_ARCHITECTURE=AMD64

This issue may be caused by the line highlighted below where the architecture is being selected by the PROCESSOR_ARCHITECTURE variable

install-scripts/src/dotnet-install.ps1

Line 158 in ede04c0

return $ENV:PROCESSOR_ARCHITECTURE

`dotnet-install.sh` fails to install on systems with a small /tmp

I have a VM with a small amount of RAM, 500MB. The /tmp tmpfs on the system is 250MB. When running dotnet-install.sh, extracting the zip fails due to running out of space (the zip is 134MB, extracting at least doubles that size, so it requires at least 268MB)

Why is /tmp even used in the first place? I can perhaps understand it for the zip download, but why not just extract it directly to the output directory? (The best solution, in my opinion, would be piping the download of a tar.gz into an extraction into the destination directory, requiring no temporary files at all...)

Also important to note is that the script fails to clean up after itself upon failure, leaving these hundred-MB files and folders lingering around in /tmp.

Expected behavior: the cli successfully installs, because installation shouldn't depend on having a large amount of RAM.

Actual behavior: Failure due to lack of RAM allocated to the /tmp tmpfs.

Use of --runtime-id generates incorrect primary URL

From @sdmaclea

./dotnet-install.sh --runtime dotnet --dry-run --version 3.0.2 --runtime-id linux-musl-x64
dotnet-install: Payload URLs:
dotnet-install: Primary named payload URL: https://dotnetcli.azureedge.net/dotnet/Runtime/3.0.2/dotnet-runtime-3.0.2-linux-x64.tar.gz
dotnet-install: Legacy named payload URL: https://dotnetcli.azureedge.net/dotnet/Runtime/3.0.2/dotnet-linux-musl-x64.3.0.2.tar.gz
dotnet-install: Repeatable invocation: ./dotnet-install.sh --version "3.0.2" --install-dir "/home/stmaclea/.dotnet" --architecture "x64" --runtime "dotnet" --runtime-id "linux-musl-x64"

I believe it should be:

./dotnet-install.sh --runtime dotnet --dry-run --version 3.0.2 --runtime-id linux-musl-x64
dotnet-install: Payload URLs:
dotnet-install: Primary named payload URL: https://dotnetcli.azureedge.net/dotnet/Runtime/3.0.2/dotnet-runtime-3.0.2-linux-musl-x64.tar.gz
dotnet-install: Legacy named payload URL: https://dotnetcli.azureedge.net/dotnet/Runtime/3.0.2/dotnet-linux-musl-x64.3.0.2.tar.gz
dotnet-install: Repeatable invocation: ./dotnet-install.sh --version "3.0.2" --install-dir "/home/stmaclea/.dotnet" --architecture "x64" --runtime "dotnet" --runtime-id "linux-musl-x64"

I was able to get the correct behavior by revising get_current_os_name() to add the highlighted section.

get_current_os_name() {
   eval $invocation

   local uname=$(uname)
   if [ "$uname" = "Darwin" ]; then
       echo "osx"
       return 0
   elif [ "$uname" = "FreeBSD" ]; then
       echo "freebsd"
       return 0        
   elif [ -n "$runtime_id" ]; then
       echo $(get_legacy_os_name_from_platform "${runtime_id%-*}" || echo "${runtime_id%-*}")
       return 0
   elif [ "$uname" = "Linux" ]; then
       local linux_platform_name
       linux_platform_name="$(get_linux_platform_name)" || { echo "linux" && return 0 ; }

       if [ "$linux_platform_name" = "rhel.6" ]; then
           echo $linux_platform_name
           return 0
       elif is_musl_based_distro; then
           echo "linux-musl"
           return 0
       else
           echo "linux"
           return 0
       fi
   fi

   say_err "OS name could not be detected: UName = $uname"
   return 1
}

`-Channel master -Version coherent` downloads 3.0, not 5.0

Is that right? If I remove "-Version coherent" it tries to get 5.0. 3.0 isn't even in support anymore.

C:\git\performance>curl -o dotnet-install.ps1 https://dotnet.microsoft.com/download/dotnet-core/scripts/v1/dotnet-install.ps1
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 39736 100 39736 0 0 39736 0 0:00:01 --:--:-- 0:00:01 497k

C:\git\performance>powershell.exe -NoProfile -ExecutionPolicy Bypass dotnet-install.ps1 -InstallDir C:\git\performance\tools\dotnet\x64 -Architecture x64 -Channel master -Version coherent
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100-preview-009817/dotnet-sdk-3.0.100-preview-009817-win-x64.zip
dotnet-install: Extracting zip from https://dotnetcli.azureedge.net/dotnet/Sdk/3.0.100-preview-009817/dotnet-sdk-3.0.100-preview-009817-win-x64.zip
dotnet-install: Adding to current process PATH: "C:\git\performance\tools\dotnet\x64\". Note: This change will not be visible if PowerShell was run as a child process.
dotnet-install: Installation finished

Write-Host and Write-Verbose are causing errors when run on Azure Functions

When we execute the scripts on Azure Functions, Write-Host and Write-Verbose calls are failing with the following error:

Write-Host : The Win32 internal error "The handle is invalid" 0x6 occurred 
while setting character attributes for the console output buffer. Contact 
Microsoft Customer Support Services.
At line:122 char:5
+     Write-Host "dotnet-install: $str"
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [Write-Host], HostExcep 
   tion
    + FullyQualifiedErrorId : SetConsoleTextAttribute,Microsoft.PowerShell.Com 
   mands.WriteHostCommand

There doesn't seem to be a fix for this, except for not using these methods.

We can instead, use Write-Output.

The difference is:

Write-Host is for specifically for displaying some information on console for the user to see (supports coloring).
Write-Output directly puts the data into output stream, so it can be piped into another process.

Scripts must have 'LF' line endings to work on macOS and Linux

This repo imposes no restrictions on the line endings of the scripts. Please ensure that the scripts always have 'LF' character at the end of each line.

Blocks #14

Request: move (public facing) dotnet-install{.sh,.ps1} scripts to this repo

Going by the conversation in this thread: dotnet/sdk#10721, I think either arcade or runtime would be the appropriate repositories for scripts like dotnet-install.sh, since very similar scripts are presently maintained and expertise are available.

My interest is to incorporate some low hanging fixes and then make it work for platforms beyond Linux, emulation environments (e.g. Linux chroot on FreeBSD) etc.

It also makes sense since arcade is the primary consumer of dotnet-install; which I believe per-day telemetry results would agree with, considering high number of CI jobs runs using Arcade SDK.

cc @wli3, @jkotas, @janvorli, for your thoughts about this suggestion?

Thank you!

Powershell Install Script Custom Path Error

Hello,

When running the following command:

powershell -executionpolicy bypass .\dotnet-install.ps1 -InstallDir "C:\Program Files\dotnet" -Channel LTS

the following is output:

dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/Files\dotnet/dotnet-sdk-Files\dotnet-win-x64.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/Files\dotnet/dotnet-sdk-Files\dotnet-win-x64.zip
dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/Files\dotnet/dotnet-dev-win-x64.Files\dotnet.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/Files\dotnet/dotnet-dev-win-x64.Files\dotnet.zip
powershell : Could not find/download: ".NET Core SDK" with version = Files\dotnet
At line:1 char:1
+ powershell -executionpolicy bypass .\dotnet-install.ps1 -InstallDir " ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (Could not find/... = Files\dotnet:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError
 
Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support
At C:\burn\dotnet-install.ps1:655 char:5
+     throw "Could not find/download: `"$assetName`" with version = $Sp ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Could not find/...ET Core support:String) [], RuntimeException
    + FullyQualifiedErrorId : Could not find/download: ".NET Core SDK" with version = Files\dotnet
Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support

As you can see, the string concatenation somehow goes wrong, leading to /dotnet/Sdk/Files\dotnet/dotnet-sdk-Files... in the first file path.

System Information:
Windows 10 Professional 1909
Powershell environment: elevated PowerShell ISE (running as another user)

When no parameters are provided, the script runs exactly as expected, leading to the DotNet sdk installing under the user's profile. However, I instead want DotNet to install under C:\Program Files\dotnet so it is available to everyone.

Work-around: Installing with the .exe installer.

dotnet-install.ps1 should be supported on unix

Steps to reproduce

Run https://dot.net/v1/dotnet-install.ps1 script on pwsh on linux or macOS

Expected behavior

Script should work

Actual behavior

Architecture not supported. If you think this is a bug, please report it at https://github.com/dotnet/cli/issues
At /Users/vors/dev/platyPS/dotnet-install.ps1:139 char:19
+ ...   default { throw "Architecture not supported. If you think this is a ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : OperationStopped: (Architecture no...tnet/cli/issues:String) [], RuntimeException
+ FullyQualifiedErrorId : Architecture not supported. If you think this is a bug, please report it at https://github.com/dotnet/cli/issues

Environment data

dotnet --info output:

n/a

I should admit that use case is pretty narrow, but it could be useful for cross-platform projects that are already utilized PowerShell.

Cache & reuse previously downloaded SDK

This is an enhancement request for install-script.ps1/.sh.

Can we get a new parameter to request that this script only download the selected SDK if it can't find a find previously downloaded SDK in the temp directory (or wherever it places the SDK archive upon download)?

I know a lot build machines these days start with a fresh image but that isn't the case for our build machines. There really is no need to re-download a several hundred MB file just to overwrite the very same file. Seems like this could also save bandwidth on Microsoft's Azure servers.

Update repo in script's exception URLs

Change repo from sdk to install-scripts under the dotnet owner in scripts' exception messages.

Example
throw "Architecture not supported. If you think this is a bug, report it at https://github.com/dotnet/sdk/issues" should be changed to throw "Architecture not supported. If you think this is a bug, report it at https://github.com/dotnet/install-scripts/issues"

Make scripts available in a CDN integrated blob storage

Our release pipeline should upload the scripts into a blob storage from where it can be accessible to any customer, including dotnet/website.

Exit criteria:

Create a release pipeline that will upload both scripts to a blob storage that is cached by a CDN.
Create an issue in dotnet/website to consume the scripts from CDN instead of keeping yet another copy in their repo

Requiring tools (libcurl) that are not needed

Separated from couple of issues bundled in #6

exit criteria

scripts ONLY perform checks for required dependencies

dotnet/cli dotnet-install-sh 3.1.100 --runtime variations

Using dotnet-install.sh on linux doesn't give inconsistent versions and I cannot update aspnetcore to current release

dotnet-install.sh -c LTS --runtime aspnetcore -DryRun
dotnet-install: Payload URLs:
dotnet-install: Primary named payload URL: https://dotnetcli.azureedge.net/dotnet/aspnetcore/Runtime/3.1.0/aspnetcore-runtime-3.1.0-linux-x64.tar.gz
dotnet-install: Repeatable invocation: ./dotnet-install.sh --version "3.1.0" --install-dir "/root/.dotnet" --architecture "x64" --runtime "aspnetcore"

dotnet-install.sh -c LTS -DryRun
dotnet-install: Payload URLs:
dotnet-install: Primary named payload URL: https://dotnetcli.azureedge.net/dotnet/Sdk/3.1.101/dotnet-sdk-3.1.101-linux-x64.tar.gz
dotnet-install: Repeatable invocation: ./dotnet-install.sh --version "3.1.101" --install-dir "/root/.dotnet" --architecture "x64"

dotnet-install.sh -c LTS --runtime dotnet -DryRun
dotnet-install: Payload URLs:
dotnet-install: Primary named payload URL: https://dotnetcli.azureedge.net/dotnet/Runtime/3.1.1/dotnet-runtime-3.1.1-linux-x64.tar.gz
dotnet-install: Repeatable invocation: ./dotnet-install.sh --version "3.1.1" --install-dir "/root/.dotnet" --architecture "x64" --runtime "dotnet"

/dotnet-install.sh -c 3.1 -runtime aspnetcore -DryRun
dotnet-install: Payload URLs:
dotnet-install: Primary named payload URL: https://dotnetcli.azureedge.net/dotnet/aspnetcore/Runtime/a1388f194c30cb21b36b75982962cb5e35954e4e/aspnetcore-runtime-a1388f194c30cb21b36b75982962cb5e35954e4e-linux-x64.tar.gz
dotnet-install: Repeatable invocation: ./dotnet-install.sh --version "a1388f194c30cb21b36b75982962cb5e35954e4e" --install-dir "/root/.dotnet" --architecture "x64" --runtime "aspnetcore

dotnet-install.ps1 should warn if the TLS settings are wrong

Related to dotnet/sdk#11269.

Steps to reproduce:

on an environment where a deprecated TLS version is used

> [Net.ServicePointManager]::SecurityProtocol
Ssl3, Tls

download the dotnet-install script from https://dot.net/v1/dotnet-install.ps1
run ./dotnet-install.ps1 -Version 5.0.100-preview.6.20318.15

Actual behavior: the script will fail without a meaningful error.
Expected behavior: the script should fail warning that the TLS version should be updated.

Known fix (taken from this comment):

> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

The full actual output before fixing the TLS version:

> ./dotnet-install.ps1 -Version 5.0.100-preview.6.20318.15
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.6.20318.15/dotnet-sdk-5.0.100-preview.6.20318.15-win-x64.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.6.20318.15/dotnet-sdk-5.0.100-preview.6.20318.15-win-x64.zip
dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.6.20318.15/dotnet-dev-win-x64.5.0.100-preview.6.20318.15.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.6.20318.15/dotnet-dev-win-x64.5.0.100-preview.6.20318.15.zip
Could not find/download: ".NET Core SDK" with version = 5.0.100-preview.6.20318.15
Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support
At C:\tools\dotnet-install.ps1:664 char:5
+     throw "Could not find/download: `"$assetName`" with version = $Sp ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Could not find/...ET Core support:String) [], RuntimeException
    + FullyQualifiedErrorId : Could not find/download: ".NET Core SDK" with version = 5.0.100-preview.6.20318.15
Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support

dotnet-install.ps1 pointing to missing bits

The dotnet/performance repo pulls down 5.0 from https://dot.net/v1/dotnet-install.ps1 which redirects to https://dotnet.microsoft.com/download/dotnet-core/scripts/v1/dotnet-install.ps1

Currently this points to nonexistent bits.

C:\git\performance>curl -o dotnet-install.ps1 https://dotnet.microsoft.com/download/dotnet-core/scripts/v1/dotnet-install.ps1
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 39736 100 39736 0 0 39736 0 0:00:01 --:--:-- 0:00:01 497k

C:\git\performance>powershell.exe -NoProfile -ExecutionPolicy Bypass ./dotnet-install.ps1 -InstallDir C:\git\performance\tools\dotnet\x64 -Architecture x64 -Channel master
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-rc.1.20403.14/dotnet-sdk-5.0.100-rc.1.20403.14-win-x64.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-rc.1.20403.14/dotnet-sdk-5.0.100-rc.1.20403.14-win-x64.zip
dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-rc.1.20403.14/dotnet-dev-win-x64.5.0.100-rc.1.20403.14.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-rc.1.20403.14/dotnet-dev-win-x64.5.0.100-rc.1.20403.14.zip
Could not find/download: ".NET Core SDK" with version = 5.0.100-rc.1.20403.14
Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support
At C:\git\performance\tools\dotnet\x64\dotnet-install.ps1:664 char:5
+ throw "Could not find/download: `"$assetName`" with version = $Sp ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Could not find/...ET Core support:String) [], RuntimeException
+ FullyQualifiedErrorId : Could not find/download: ".NET Core SDK" with version = 5.0.100-rc.1.20403.14
Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support

cc @donJoseLuis

[dotnet-install.ps1] Incorrect auto architecture when running from Powershell classic on Windows ARM64

When running dotnet-install.ps1 from Powershell classic on Windows ARM64 without an -Architecture specified, the installer will resolve to downloading an x86 build of the sdk.

The reason seems to be this line, Powershell classic runs as emulated x86 so the return value is, accordingly, x86. As expected, the issue does not impact powershell core.

We should probably update the script so that the processor architecture is determined via different means. One potential solution is using the windows command wmic OS get OSArchitecture, which reports the correct OS architecture. If you agree with this solution I could perhaps try to contribute a PR that fixes the problem.

We've been seeing this issue in the windows arm64 builds of dotnet/runtime, which is using dotnet-install.ps1 and powershell classic to download its bootstrapping sdk. cc @safern @ViktorHofer

dotnet-install.sh gives wrong path when using "source" on macOS 10.13

Steps to reproduce

echo $PATH # results in: "/my/original/path:/other/original/path"
curl -s https://dot.net/v1/dotnet-install.sh
source ./dotnet-install.sh
echo $PATH # results in: "Saving session.../.dotnet:/my/original/path:/other/original/path"

Expected behavior

echo $PATH should result in "/Users/jonathann92/.dotnet/:/my/original/path:/other/original/path"

Actual behavior

echo $PATH results in: "Saving session.../.dotnet:/my/original/path:/other/original/path"

Environment data

dotnet --info output: Not relevant because im installing dotnet.

Output for running `bash ./dotnet-install.sh`

% bash ./dotnet-install.sh 
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.403/dotnet-sdk-2.1.403-osx-x64.tar.gz
dotnet-install: Extracting zip from https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.403/dotnet-sdk-2.1.403-osx-x64.tar.gz
dotnet-install: Adding to current process PATH: `/Users/jnguyen/.dotnet`. Note: This change will be visible only when sourcing script.
dotnet-install: Installation finished successfully.

Output for running `source ./dotnet-install.sh`

% source ./dotnet-install.sh 
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.403/dotnet-sdk-2.1.403-osx-x64.tar.gz
dotnet-install: Extracting zip from https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.403/dotnet-sdk-2.1.403-osx-x64.tar.gz
-bash: rvm_bash_nounset: unbound variable
-bash: HISTTIMEFORMAT: unbound variable
dotnet-install: Adding to current process PATH: `Saving session.../.dotnet`. Note: This change will be visible only when sourcing script.
dotnet-install: Installation finished successfully.

Cannot download for master branch latest version

Failed to download latest version from master branch:

C:\work\testinstall> .\dotnet-install.ps1 -Channel master -Version latest -Architecture x64 -i "C:\work\testinstall"
dotnet-install: Downloading link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.7.20325.10/dotnet-sdk-5.0.100-preview.7.20325.10-win-x64.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.7.20325.10/dotnet-sdk-5.0.100-preview.7.20325.10-win-x64.zip
dotnet-install: Downloading legacy link: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.7.20325.10/dotnet-dev-win-x64.5.0.100-preview.7.20325.10.zip
dotnet-install: Cannot download: https://dotnetcli.azureedge.net/dotnet/Sdk/5.0.100-preview.7.20325.10/dotnet-dev-win-x64.5.0.100-preview.7.20325.10.zip

Probable cut/paste prerequisite typo

install-scripts/src/dotnet-install.sh

Line 273 in ede04c0

 [ -z "$($LDCONFIG_COMMAND 2>/dev/null | grep lttng)" ] && say_warning "Unable to locate liblttng. Probable prerequisite missing; install libcurl." 

Unable to locate liblttng. Probable prerequisite missing; install libcurl

dotnet / install-scripts Goto Github PK

install-scripts's Introduction

install-scripts's People

Stargazers

Watchers

Forkers

install-scripts's Issues

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Originally from

Document Details

Document Details

Issue Description

Steps to reproduce

Expected behavior

Actual behavior

Workaround

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Steps to reproduce

Expected behavior

Actual behavior

Environment data

Output for running bash ./dotnet-install.sh

Output for running source ./dotnet-install.sh

Recommend Projects

Recommend Topics

Recommend Org

Output for running `bash ./dotnet-install.sh`

Output for running `source ./dotnet-install.sh`