DOTNET_HOME not used when looking for SDK
jgoz opened this issue · comments
I have installed (via scoop) .NET Core 3.0 preview on my build agents and have set the DOTNET_HOME environment variable to the install path per the README instructions. The build is started with the correct executable version (.NET Core SDK v3.0.100-preview5-011568), but it fails quickly with this error message:
error NETSDK1045: The current .NET SDK does not support targeting .NET Core 3.0. Either target .NET Core 2.1 or lower, or use a version of the .NET SDK that supports .NET Core 3.0.
This leads me to believe that the SDK path lookup is not respecting the DOTNET_HOME environment variable.
The workaround is to use a Command Line build step and invoke dotnet.exe directly, but it would be preferable if both the executable and the SDK lookup respected DOTNET_HOME.
(These are Windows build agents).
Associated log output:
[2019-05-10 08:28:02,964] INFO - tnet.DotnetPropertiesExtension - .NET CLI BeforeAgentConfigurationLoadedEvent(agent=jetbrains.buildServer.agent.impl.BuildAgentImpl@67c119b7) found at "C:\Program Files\dotnet\dotnet.exe"
[2019-05-10 08:28:02,964] INFO - r.dotnet.DotnetCliToolInfoImpl - Try getting the dotnet CLI version for directory "C:\Build".
[2019-05-10 08:28:02,964] INFO - .agent.CommandLineExecutorImpl - Execute command line: "C:\Program Files\dotnet\dotnet.exe" --version
[2019-05-10 08:28:03,057] INFO - .agent.CommandLineExecutorImpl - Exits with code: 0
[2019-05-10 08:28:03,057] INFO - r.dotnet.DotnetCliToolInfoImpl - Try getting the dotnet SDKs using the command "dotnet CommandLineArgument(value=--list-sdks)".
[2019-05-10 08:28:03,057] INFO - .agent.CommandLineExecutorImpl - Execute command line: "C:\Program Files\dotnet\dotnet.exe" --list-sdks
[2019-05-10 08:28:03,104] INFO - .agent.CommandLineExecutorImpl - Exits with code: 0
[2019-05-10 08:28:03,104] INFO - tnet.DotnetPropertiesExtension - .NET Core SDK 2.1 found at "C:\Program Files\dotnet\sdk\2.1.504"
[2019-05-10 08:28:03,104] INFO - tnet.DotnetPropertiesExtension - .NET Core SDK 2.1.104 found at "C:\Program Files\dotnet\sdk\2.1.104"
[2019-05-10 08:28:03,104] INFO - tnet.DotnetPropertiesExtension - .NET Core SDK 2.1.200 found at "C:\Program Files\dotnet\sdk\2.1.200"
[2019-05-10 08:28:03,104] INFO - tnet.DotnetPropertiesExtension - .NET Core SDK 2.1.201 found at "C:\Program Files\dotnet\sdk\2.1.201"
[2019-05-10 08:28:03,104] INFO - tnet.DotnetPropertiesExtension - .NET Core SDK 2.1.202 found at "C:\Program Files\dotnet\sdk\2.1.202"
[2019-05-10 08:28:03,104] INFO - tnet.DotnetPropertiesExtension - .NET Core SDK 2.1.401 found at "C:\Program Files\dotnet\sdk\2.1.401"
[2019-05-10 08:28:03,104] INFO - tnet.DotnetPropertiesExtension - .NET Core SDK 2.1.402 found at "C:\Program Files\dotnet\sdk\2.1.402"
[2019-05-10 08:28:03,104] INFO - tnet.DotnetPropertiesExtension - .NET Core SDK 2.1.500 found at "C:\Program Files\dotnet\sdk\2.1.500"
[2019-05-10 08:28:03,104] INFO - tnet.DotnetPropertiesExtension - .NET Core SDK 2.1.504 found at "C:\Program Files\dotnet\sdk\2.1.504"
DOTNET_HOME set to C:\Users\agentworker\scoop\apps\dotnet-sdk-preview\current\, but this value does not show up in probing even though the executable is being used properly in the build.
Setting sdk.version to 3.0.100-preview5-011568 in global.json resulted in an error message:
Cannot find the .NET Core SDK v0.0.0
Currently bumping on this.
dotnet is running on the Debian server. I have .NET Core on 2.1.603. DOTNET_HOME (and I tried DOTNET_ROOT before) is set on /home/teamcity/dotnet. Path has /home/teamcity/dotnet in it.
Teamcity doesn't pick up dotnet, and therefore, doens't allow Octopus releases.
We have the error message "jetbrains.buildServer.AGENT - Octopus can not run on agent with Unix and without Octo.exe or DotNET".
Currently working with the support for that, surprised to see other people actually had that issue as well
- how did you specify DOTNET_HOME?
- could you make sure this path contains executable file like dotnet.exe (for windows)
- which windows account did you use to run TeamCity agent? could you make sure that the command line
setunder this windows account returns the appropriate path (just add the command line runner with the commandset)?
@oceaneLonneux
could you make sure the environment variable DOTNET_HOME was defined correctly like in my previous post (command line step to show defined environment variables).
It is important to note that the DOTNET_HOME environment variable should be defined on a TeamCity agent computer for the account which was used to run TeamCity agent.
This plugin knows nothing about the DOTNET_ROOT environment variable, it knows about DOTNET_HOME only
Hello, so I finally figured out what happened in this case.
Was using the octopus deploy plugin, which needed dotnet. Installed 2.1 dotnet and wasn't working (with /home/user/dotnet). updated to 2.2 with this command
sudo apt-get install dotnet-sdk-2.2
It updated itself, rebooted the servers and now it’s working. For some reasons, the plugin couldn't see the 2.1 (maybe because older?) version. We are using a Debian build server.
@oceaneLonneux If you are meaning the dotnet CLI plugin, it does not matter for it the SDK version because of it does not interact with SDK directly, it does it via dotnet command lines like dotnet --info or dotnet --version to get info. Are you still having some unresolved issues?
Not exactly. We already have the dotnet cli plugin and the updated ocotpus deploy release plugin on the windows master. But we got a debian build agent. We installed 2.1 of dotnet on it, and neither of the steps "octopus deploy release" or "dotnet" was working.
It fixed itself when I updated to version 2.2 of dotnet, which lead me to think maybe teamcity didn't pick up that version correctly, even though on the server, when I ran dotnet --version, it ran fine.
This issue is resolved for me, but I don't think I've seen documentation about that version requirement.
- how did you specify DOTNET_HOME?
It is configured as an environment variable in the parameters of a specific build configuration.
- could you make sure this path contains executable file like dotnet.exe (for windows)
Yes, the path was set to C:\Users\agentworker\scoop\apps\dotnet-sdk-preview\current\, which contained dotnet.exe.
- which windows account did you use to run TeamCity agent? could you make sure that the command line set under this windows account returns the appropriate path (just add the command line runner with the command set)?
We have a domain account that we use on all of our agents. Since we are defining DOTNET_HOME in the parameters for a build configuration, I would only expect it to be defined when that specific build is running, which it is (I have confirmed it via the agent parameters).
@NikolayPianikov The issue here is that the SDK path is not being found, even though the correct executable is being used.
Browsing through the code, I believe the issue is that this line should actually be more like this line. But I might be wrong about that.
Either way, this is the behaviour we are seeing:
- Executable path is being found correctly by specifying DOTNET_HOME in build parameters
- SDK path is not being found even though the executable is
@jgoz I understand your point. The TeamCity agent is finding dotnet executable once and is storing the path to dotnet to configuration parameter DotNetCLI_Path on the TeamCity agent starting. To do it each time before running build step might be not efficient.
But for your case you could just override the configuration parameter DotNetCLI_Path for your project or build configuration, for instance like DotNetCLI_Path = C:\Users\agentworker\scoop\apps\dotnet-sdk-preview\current\dotnet.exe.
@oceaneLonneux thanks for info. We supposed that any of dotnet versions should work fine. I will ask QA check 2.1 on Debian
@NikolayPianikov I tried your suggestion:
- Defined
DotNetCLI_Pathconfiguration parameter pointing to sdk-preview executable (defined at project level)
It did not work. This is the relevant build output:
[09:33:35]Step 1/1: Build + Test (.NET CLI (dotnet))
[09:33:36][Step 1/1] .NET Core SDK v3.0.100-preview5-011568 dotnet.exe test MySolution.sln @C:\BuildAgent\temp\agentTmp\1.rsp
[09:33:36][Step 1/1] test
[09:33:36][test] Starting: "C:\Program Files\dotnet\dotnet.exe" test MySolution.sln @C:\BuildAgent\temp\agentTmp\1.rsp
[09:33:36][test] in directory: C:\Build\a56fb97e1200ab77
[09:33:36][test] A compatible SDK version for global.json version: [3.0.100-preview5-011568] from [C:\Build\a56fb97e1200ab77\global.json] was not found
[09:33:36][test] Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
[09:33:36][test] https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
[09:33:36][test] Process exited with code -2147450735
[09:33:36][Step 1/1] Process exited with code -2147450735
[09:33:36][Step 1/1] Step Build + Test (.NET CLI (dotnet)) failed
It appears to be using the correct executable version again, but cannot find the associated SDK.
I also tried defining the DotNetCoreSDK3.0.100-preview5-011568_Path configuration parameter to point to the actual SDK path, but that failed with the same error.
@jgoz try updating (Installing a plugin via Web UI) dotnet cli plugin:
dotnet.cli.zip
Related issue
@NikolayPianikov Thank you, it now works if I define DotNetCLI_Path per your earlier instructions. 🎉
I also tried only defining DOTNET_HOME and it failed with Cannot find the .NET Core SDK v0.0.0 for the directory.... But this isn't an issue now that we can use the configuration parameter.
Thank you for the quick resolution!
Fixed in 2019.2