How to install .NET Core SDK 2.1.401 after having installed version 2.1.500?
up vote
0
down vote
favorite
I am running Windows 7 Home Premium 64-bit.
I updated my .NET Core installation to the latest version 2.1.500
a few days ago.
Shortly after, I wanted to play with the source code for MS Build, so I cloned the MS Build git repo and ran their build.cmd
file as instructed.
But it kept failing telling me it wasn't able to download the per-requisite .NET Core version 2.1.401
.
C:SourceOfMSBuild> build.cmd
dotnet-install: Downloading link:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
dotnet-install: Cannot download:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
dotnet-install: Downloading legacy link:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-dev-win-x64.2.1.401.zip
Exception calling "Invoke" with "0" argument(s):
"Failed to download
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-dev-win-x64.2.1.401.zip."
yada yada yada yada...
So I downloaded the zip file https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
manually, and unzipped it to find a dotnet.exe
in it.
First thinking that it was a set-up file, I double-clicked it. It appeared and disappeared quickly.
Then, after a few failed attempts, I suspected it was indeed the SDK itself and wasn't an install-able set-up. So, I checked the folders in the unzipped file and they matched exactly the folders in my C:Program Filesdotnet
folder (see the picture at the bottom of this question).
So, now, I don't know how to have this version of .NET Core that I just downloaded (v 2.1.401
) co-exist with the latest version 2.1.500.
I do see that the C:Program Filesdotnetsdk
folder has several versions exist side by side:
C:Program Filesdotnetsdk>dir /b
1.0.0
1.0.0-preview2-003131
2.1.500
NuGetFallbackFolder
So, should I just go ahead and mess around with my folders manually? That is, should I just copy and paste the folders I downloaded and merge them with what I have? See below.
.net-core
add a comment |
up vote
0
down vote
favorite
I am running Windows 7 Home Premium 64-bit.
I updated my .NET Core installation to the latest version 2.1.500
a few days ago.
Shortly after, I wanted to play with the source code for MS Build, so I cloned the MS Build git repo and ran their build.cmd
file as instructed.
But it kept failing telling me it wasn't able to download the per-requisite .NET Core version 2.1.401
.
C:SourceOfMSBuild> build.cmd
dotnet-install: Downloading link:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
dotnet-install: Cannot download:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
dotnet-install: Downloading legacy link:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-dev-win-x64.2.1.401.zip
Exception calling "Invoke" with "0" argument(s):
"Failed to download
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-dev-win-x64.2.1.401.zip."
yada yada yada yada...
So I downloaded the zip file https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
manually, and unzipped it to find a dotnet.exe
in it.
First thinking that it was a set-up file, I double-clicked it. It appeared and disappeared quickly.
Then, after a few failed attempts, I suspected it was indeed the SDK itself and wasn't an install-able set-up. So, I checked the folders in the unzipped file and they matched exactly the folders in my C:Program Filesdotnet
folder (see the picture at the bottom of this question).
So, now, I don't know how to have this version of .NET Core that I just downloaded (v 2.1.401
) co-exist with the latest version 2.1.500.
I do see that the C:Program Filesdotnetsdk
folder has several versions exist side by side:
C:Program Filesdotnetsdk>dir /b
1.0.0
1.0.0-preview2-003131
2.1.500
NuGetFallbackFolder
So, should I just go ahead and mess around with my folders manually? That is, should I just copy and paste the folders I downloaded and merge them with what I have? See below.
.net-core
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am running Windows 7 Home Premium 64-bit.
I updated my .NET Core installation to the latest version 2.1.500
a few days ago.
Shortly after, I wanted to play with the source code for MS Build, so I cloned the MS Build git repo and ran their build.cmd
file as instructed.
But it kept failing telling me it wasn't able to download the per-requisite .NET Core version 2.1.401
.
C:SourceOfMSBuild> build.cmd
dotnet-install: Downloading link:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
dotnet-install: Cannot download:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
dotnet-install: Downloading legacy link:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-dev-win-x64.2.1.401.zip
Exception calling "Invoke" with "0" argument(s):
"Failed to download
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-dev-win-x64.2.1.401.zip."
yada yada yada yada...
So I downloaded the zip file https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
manually, and unzipped it to find a dotnet.exe
in it.
First thinking that it was a set-up file, I double-clicked it. It appeared and disappeared quickly.
Then, after a few failed attempts, I suspected it was indeed the SDK itself and wasn't an install-able set-up. So, I checked the folders in the unzipped file and they matched exactly the folders in my C:Program Filesdotnet
folder (see the picture at the bottom of this question).
So, now, I don't know how to have this version of .NET Core that I just downloaded (v 2.1.401
) co-exist with the latest version 2.1.500.
I do see that the C:Program Filesdotnetsdk
folder has several versions exist side by side:
C:Program Filesdotnetsdk>dir /b
1.0.0
1.0.0-preview2-003131
2.1.500
NuGetFallbackFolder
So, should I just go ahead and mess around with my folders manually? That is, should I just copy and paste the folders I downloaded and merge them with what I have? See below.
.net-core
I am running Windows 7 Home Premium 64-bit.
I updated my .NET Core installation to the latest version 2.1.500
a few days ago.
Shortly after, I wanted to play with the source code for MS Build, so I cloned the MS Build git repo and ran their build.cmd
file as instructed.
But it kept failing telling me it wasn't able to download the per-requisite .NET Core version 2.1.401
.
C:SourceOfMSBuild> build.cmd
dotnet-install: Downloading link:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
dotnet-install: Cannot download:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
dotnet-install: Downloading legacy link:
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-dev-win-x64.2.1.401.zip
Exception calling "Invoke" with "0" argument(s):
"Failed to download
https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-dev-win-x64.2.1.401.zip."
yada yada yada yada...
So I downloaded the zip file https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.401/dotnet-sdk-2.1.401-win-x64.zip
manually, and unzipped it to find a dotnet.exe
in it.
First thinking that it was a set-up file, I double-clicked it. It appeared and disappeared quickly.
Then, after a few failed attempts, I suspected it was indeed the SDK itself and wasn't an install-able set-up. So, I checked the folders in the unzipped file and they matched exactly the folders in my C:Program Filesdotnet
folder (see the picture at the bottom of this question).
So, now, I don't know how to have this version of .NET Core that I just downloaded (v 2.1.401
) co-exist with the latest version 2.1.500.
I do see that the C:Program Filesdotnetsdk
folder has several versions exist side by side:
C:Program Filesdotnetsdk>dir /b
1.0.0
1.0.0-preview2-003131
2.1.500
NuGetFallbackFolder
So, should I just go ahead and mess around with my folders manually? That is, should I just copy and paste the folders I downloaded and merge them with what I have? See below.
.net-core
.net-core
asked Nov 22 at 9:35
Water Cooler v2
12.1k2999196
12.1k2999196
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
The contents of the two folders needn't have to be merged. One must download the .NET Core installer instead.
Two issues need to be addressed in answering this question.
I had downloaded the binaries in a zip file and not an installer. I was led to install the binaries because the URL I saw on the console when I ran the build script pointed to the binaries and not to the installer.
.NET Core comes in two kinds of packages:
a. MSI installers; and
b. Zip files containing the binaries. These are useful when you want to hold a private copy of .NET core in your application. Just like NPM packages have private installations in contrast to public/global ones. Just like you hold private assemblies (
CopyLocal = True
) of the .NET framework within your application in contrast with references them from the GAC or the Reference Assemblies folder.
Look at this SDK download page on the Microsoft website. It lists both, the binaries and the installers for each version of the SDK and the runtime.
A Powershell script in the MS Build build process downloads the zip file containing only the binaries and it holds this version of the .NET Core privately. The version it is looking for is mentioned in the
DotNetCliVersion
property in theVersion.props
file.
From build1.ps
function Build {
if (![string]::IsNullOrEmpty($DotNetCoreSdkDir) -and
(Test-Path -Path $DotNetCoreSdkDir)) {
$env:DOTNET_INSTALL_DIR = $DotNetCoreSdkDir
}
else {
InstallDotNetCli
}
$env:DOTNET_HOST_PATH = Join-Path $env:DOTNET_INSTALL_DIR "dotnet.exe"
...
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
The contents of the two folders needn't have to be merged. One must download the .NET Core installer instead.
Two issues need to be addressed in answering this question.
I had downloaded the binaries in a zip file and not an installer. I was led to install the binaries because the URL I saw on the console when I ran the build script pointed to the binaries and not to the installer.
.NET Core comes in two kinds of packages:
a. MSI installers; and
b. Zip files containing the binaries. These are useful when you want to hold a private copy of .NET core in your application. Just like NPM packages have private installations in contrast to public/global ones. Just like you hold private assemblies (
CopyLocal = True
) of the .NET framework within your application in contrast with references them from the GAC or the Reference Assemblies folder.
Look at this SDK download page on the Microsoft website. It lists both, the binaries and the installers for each version of the SDK and the runtime.
A Powershell script in the MS Build build process downloads the zip file containing only the binaries and it holds this version of the .NET Core privately. The version it is looking for is mentioned in the
DotNetCliVersion
property in theVersion.props
file.
From build1.ps
function Build {
if (![string]::IsNullOrEmpty($DotNetCoreSdkDir) -and
(Test-Path -Path $DotNetCoreSdkDir)) {
$env:DOTNET_INSTALL_DIR = $DotNetCoreSdkDir
}
else {
InstallDotNetCli
}
$env:DOTNET_HOST_PATH = Join-Path $env:DOTNET_INSTALL_DIR "dotnet.exe"
...
add a comment |
up vote
0
down vote
accepted
The contents of the two folders needn't have to be merged. One must download the .NET Core installer instead.
Two issues need to be addressed in answering this question.
I had downloaded the binaries in a zip file and not an installer. I was led to install the binaries because the URL I saw on the console when I ran the build script pointed to the binaries and not to the installer.
.NET Core comes in two kinds of packages:
a. MSI installers; and
b. Zip files containing the binaries. These are useful when you want to hold a private copy of .NET core in your application. Just like NPM packages have private installations in contrast to public/global ones. Just like you hold private assemblies (
CopyLocal = True
) of the .NET framework within your application in contrast with references them from the GAC or the Reference Assemblies folder.
Look at this SDK download page on the Microsoft website. It lists both, the binaries and the installers for each version of the SDK and the runtime.
A Powershell script in the MS Build build process downloads the zip file containing only the binaries and it holds this version of the .NET Core privately. The version it is looking for is mentioned in the
DotNetCliVersion
property in theVersion.props
file.
From build1.ps
function Build {
if (![string]::IsNullOrEmpty($DotNetCoreSdkDir) -and
(Test-Path -Path $DotNetCoreSdkDir)) {
$env:DOTNET_INSTALL_DIR = $DotNetCoreSdkDir
}
else {
InstallDotNetCli
}
$env:DOTNET_HOST_PATH = Join-Path $env:DOTNET_INSTALL_DIR "dotnet.exe"
...
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
The contents of the two folders needn't have to be merged. One must download the .NET Core installer instead.
Two issues need to be addressed in answering this question.
I had downloaded the binaries in a zip file and not an installer. I was led to install the binaries because the URL I saw on the console when I ran the build script pointed to the binaries and not to the installer.
.NET Core comes in two kinds of packages:
a. MSI installers; and
b. Zip files containing the binaries. These are useful when you want to hold a private copy of .NET core in your application. Just like NPM packages have private installations in contrast to public/global ones. Just like you hold private assemblies (
CopyLocal = True
) of the .NET framework within your application in contrast with references them from the GAC or the Reference Assemblies folder.
Look at this SDK download page on the Microsoft website. It lists both, the binaries and the installers for each version of the SDK and the runtime.
A Powershell script in the MS Build build process downloads the zip file containing only the binaries and it holds this version of the .NET Core privately. The version it is looking for is mentioned in the
DotNetCliVersion
property in theVersion.props
file.
From build1.ps
function Build {
if (![string]::IsNullOrEmpty($DotNetCoreSdkDir) -and
(Test-Path -Path $DotNetCoreSdkDir)) {
$env:DOTNET_INSTALL_DIR = $DotNetCoreSdkDir
}
else {
InstallDotNetCli
}
$env:DOTNET_HOST_PATH = Join-Path $env:DOTNET_INSTALL_DIR "dotnet.exe"
...
The contents of the two folders needn't have to be merged. One must download the .NET Core installer instead.
Two issues need to be addressed in answering this question.
I had downloaded the binaries in a zip file and not an installer. I was led to install the binaries because the URL I saw on the console when I ran the build script pointed to the binaries and not to the installer.
.NET Core comes in two kinds of packages:
a. MSI installers; and
b. Zip files containing the binaries. These are useful when you want to hold a private copy of .NET core in your application. Just like NPM packages have private installations in contrast to public/global ones. Just like you hold private assemblies (
CopyLocal = True
) of the .NET framework within your application in contrast with references them from the GAC or the Reference Assemblies folder.
Look at this SDK download page on the Microsoft website. It lists both, the binaries and the installers for each version of the SDK and the runtime.
A Powershell script in the MS Build build process downloads the zip file containing only the binaries and it holds this version of the .NET Core privately. The version it is looking for is mentioned in the
DotNetCliVersion
property in theVersion.props
file.
From build1.ps
function Build {
if (![string]::IsNullOrEmpty($DotNetCoreSdkDir) -and
(Test-Path -Path $DotNetCoreSdkDir)) {
$env:DOTNET_INSTALL_DIR = $DotNetCoreSdkDir
}
else {
InstallDotNetCli
}
$env:DOTNET_HOST_PATH = Join-Path $env:DOTNET_INSTALL_DIR "dotnet.exe"
...
edited Nov 26 at 7:28
answered Nov 26 at 7:22
Water Cooler v2
12.1k2999196
12.1k2999196
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53427817%2fhow-to-install-net-core-sdk-2-1-401-after-having-installed-version-2-1-500%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown