Repository navigation
.NET Core tools version check in build.psm1 blocks the build #5260
Description
Condition in build.psm1 seems to be looking for exact match with "2.0.0", while the tools are of "2.0.2". This blocks the build.
$dotnetCLIRequiredVersion = "2.0.0"
...
# Verify if the dotnet in-use is the required version
$dotnetCLIInstalledVersion = (dotnet --version)
If ($dotnetCLIInstalledVersion -ne $dotnetCLIRequiredVersion) {
Write-Warning @"
The currently installed .NET Command Line Tools is not the required version.
...
Expected behavior:
Build succeeds.
Actual behavior
Build stops at warning:
Steps to reproduce
git clone --recursive https://github.com/PowerShell/PowerShell.git
Import-Module ./build.psm1
Start-PSBootstrap
Start-PSBuild
Environment data
Name Value
---- -----
PSVersion 5.1.17025.1001
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.17025.1001
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Activity
rkeithhill commentedon Oct 27, 2017
Do you have a
global.jsonfile in the root of the repo? It's contents should specify that PowerShell currently uses the 2.0.0 version of the SDK. The gist is that the presence of this file should causedotnet --versionto return2.0.0if that command is run within the repo dir structure. From that code snippet, I can't tell which dir the command is run from. I suspect the dir isn't being set to the repo path which would cause this problem.Try this, cd into your local PowerShell repo and run
dotnet --version. What version do you get?anmenaga commentedon Oct 27, 2017
All commands are run from PowerShell repo root
C:\github\PowerShellrkeithhill commentedon Oct 27, 2017
Hmm, that is not what I see but I have both 2.0.0 and 2.0.2 installed. Which versions do you have in your
C:\Program Files\dotnet\sdkandC:\Users\anmenaga\AppData\Local\Microsoft\dotnet\sdkfolders?anmenaga commentedon Oct 27, 2017
rkeithhill commentedon Oct 27, 2017
Anything in the
C:\Users\anmenaga\AppData\Local\Microsoft\dotnet\sdkfolder?anmenaga commentedon Oct 27, 2017
rkeithhill commentedon Oct 27, 2017
Hmm, I wonder why
dotnetis not seeing the sdk under you AppData dir. As an experiment, would you be willing to install the .NET SDK from here, restart PowerShell and then re-rundotnet --versionfrom the PowerShell repo folder. Does that still report 2.0.2?IISResetMe commentedon Oct 28, 2017
Can't we optimize the version check in
build.psm1to do ordinal version comparison after validating the major version of the dotnet CLI?PowerShell seems to compile just fine with version
2.0.2rkeithhill commentedon Oct 28, 2017
There's definitely an argument to be made to simply let global.json inform of
dotnetof the desired version of the SDK and letdotnetdetermine compatibility.That said, it seems like there is a bug in
dotnetbecause on my system with both 2.0.0 and 2.0.2,dotnet --versionreports2.0.0in the PowerShell repo. Not sure why the OP isn't seeing the same thing given they also have both the 2.0.2 and 2.0.0 SDK installed.iSazonov commentedon Oct 29, 2017
We decided to use a fixed version after a number of compatibility problems.
We now expect 2.0.3 version with important patches.
iSazonov commentedon Oct 29, 2017
Maybe related https://github.com/dotnet/cli/issues/6836
rkeithhill commentedon Oct 30, 2017
It appears that perhaps the PowerShell build is installing the .NET Core SDK into a place that isn't ideal. https://github.com/dotnet/cli/issues/7928#issuecomment-340522972
Andrew (@anmenaga) This answers the question as to why you're seeing this error. Installing the .NET Core 2.0 SDK from https://www.microsoft.com/net/download/core will get you around this issue.
Question for PowerShellTeam, why does the build system install into the user's AppData folder instead of the normal program files location? Because of the need to elevate? As it stands now, the global.json file apparently will not help unless the user has installed .NET Core SDK ahead of time.
anmenaga commentedon Nov 1, 2017
Thanks Keith Hill (@rkeithhill)
An interesting observation...
On my machine "Program Files\dotnet" location (with version 2.0.2) was in %PATH% system-wide env var. Looks like it was added there when I recently installed Visual Studio 2017 (I've confirmed on a clean machine that VS2017 adds to the %PATH% system-wide env var).
When I changed %PATH% env var to have AppData|2.0.0 location instead - things started working again.
iSazonov commentedon Nov 1, 2017
Should we document this and/or add a check in Start-PSBootStrap?
daxian-dbw commentedon Nov 2, 2017
We use the
dotnet-install.ps1script from 'dotnet/cli' repo to install dotnet sdk, and it installs dontet to AppData folder by default.The
global.jsonfile did resolve the same build issue in our AppVeyor CI about 2 weeks ago. It seemed there was an update to the "Server 2016+VS2107" image we are using in AppVeyor. The new image has dotnet installed inProgram Files, and causedStart-PSBuildto stop working. Then we merged the PR #5118 and the CI started to work again. I guess that was because the dotnet installed atProgram Fileshas both 2.0.2 and 2.0.0 installed (need to verify it myself).daxian-dbw commentedon Nov 2, 2017
Just verified on an AppVeyor builder. The
dotnetSDK installed atC:\Program Files\dotnethas the following versions installed. That's whyglobal.jsonfixed the CI runs.rkeithhill commentedon Nov 4, 2017
Got this info from the dotnet/cli folks:
It appears to me that this is likely to work correctly the first time the user bootstraps the build env as the install-dotnet script adds the download path (user's appdata dir) to the PowerShell process's path. After that session is closed, the user is at the mercy of what they have officially installed AFAICT because the build script is executing
dotnetas indotnet --version,dotnet restore, etc. There is no attempt to use the version of dotnet that the bootstrapper installed. This seems a bit perilous.One option is to use the install-dotnet script to install into
$env:ProgramFiles\dotnet(on Windows) but would require elevation. Another option is to configure$dotnetas a path to the executable where that path is under the user's app data folder. Finally, you could try setting$env:MULTI_LEVEL_LOOKUP="false"but I'm still a little fuzzy as to what that actually does.rkeithhill commentedon Nov 4, 2017
I've been looking at how the PowerShellEditorServices does this. It installs into a
.dotnetfolder at the root of the repo. You'd need to gitignore that but that is another option to consider.rkeithhill commentedon Nov 4, 2017
OK did a bit more investigating into this. I removed the 2.0.2 SDK that was in my
C:\Program Files\dotnet\sdkdir and also removed the one from my app data dir. Then I bootstrapped and tried to build w/no joy:The problem is that the
precheckmethod is looking for anydotnetin the path. In this case, it finds thedotnetinC:\Program Files\dotnetwhich is not able to see the SDK that was just downloaded.This can be fixed by having
Find-Dotnetfirst check to see if dotnet is in the current path and if so, does it have the required SDK version. If it does then we use it. Mostly likely this dotnet is the global dotnet in which case we avoided installing dotnet when it doesn't need to be installed.More importantly though, we don't settle on a version of dotnet (global) that doesn't have the required SDK. In the case the globally installed dotnet doesn't have the required SDK, we prepend the user's local path for dotnet. If we can't find dotnet or the required SDK in the user's local dotnet dir, this triggers a user local installation of dotnet.
PR coming on this.
Update Find-Dotnet to find dotnet with compat SDK
Update Find-Dotnet to find dotnet with compat SDK (#5341)
Update Find-Dotnet to find dotnet with compat SDK (PowerShell#5341)