-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
CentOS 7, .NET SDK Support 1.1.1
Installing and then attempting to use a .NET global tool (e.g., dotnet-reportgenerator-globaltool) with a dynamically installed .NET 5 setup fails. A simple reproduction:
pipeline { agent { label 'centos' // this is a label for our CentOS 7 nodes } tools { dotnetsdk '5.0' } stages { stage('Test') { steps { sh ''' dotnet tool install dotnet-reportgenerator-globaltool --tool-path .' reportgenerator -help ''' } } } }
This results in:
+ dotnet tool update dotnet-reportgenerator-globaltool --tool-path . You can invoke the tool using the following command: reportgenerator Tool 'dotnet-reportgenerator-globaltool' (version '4.8.12') was successfully installed. + ./reportgenerator '-reports:**/*cobertura*.xml' -targetdir:MergedCoverage -reporttypes:Cobertura A fatal error occurred. The required library libhostfxr.so could not be found. ... etc. ...
If I set `DOTNET_ROOT`, it works:
pipeline { agent { label 'centos' } tools { dotnetsdk '5.0' } stages { stage('Test') { steps { sh ''' export DOTNET_ROOT=\$(dirname \$(realpath \$(which dotnet))) dotnet tool install dotnet-reportgenerator-globaltool --tool-path .' reportgenerator -help ''' } } } }
See https://github.com/dotnet/sdk/issues/12359 for background. It seems that this is an environment variable that this plugin should set when installing a .NET SDK.
- links to
[JENKINS-66120] Missing DOTNET_ROOT value breaks dotnet global tool usage on Linux
Remote Link | New: This issue links to "PR for the fix (Web Link)" [ 26820 ] |
Resolution | New: Fixed [ 1 ] | |
Status | Original: Open [ 1 ] | New: Fixed but Unreleased [ 10203 ] |
Released As | New: https://github.com/jenkinsci/dotnet-sdk-plugin/releases/tag/dotnet-sdk-1.1.2 | |
Status | Original: Fixed but Unreleased [ 10203 ] | New: Closed [ 6 ] |
Interesting - I was not aware the .NET SDK had its own "JAVA_HOME" style variable.
I was already setting DOTNET_SDK_JENKINS_TOOL_HOME to that path, so should be easy to set DOTNET_ROOT too.