-
Bug
-
Resolution: Not A Defect
-
Major
-
Jenkins version: 2.249.2 (LTS at the time of writing)
OS: Debian 9 (stretch) running in Docker container.
.NET SDK Support plugin version: 1.0.0
I'm new to Jenkins and wanted to try how it works with .NET Core 3.1, so I downloaded and ran the docker LTS image (jenkins/jenkins:lts) which is based on Debian 9 (stretch)
I installed the ".NET SDK Support" plugin, went to "Global tool configuration", added the .NET SDK with "install from microsoft.com" installer.
I ran my first build, it downloaded & installed .NET SDK 3.1, but then dotnet build command failed with the error: "Couldn't find a valid ICU package installed on the system. Set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support."
I've seen this error before when trying out .NET Core 3.1 on Ubuntu, and the problem as I remember was that I was missing an older version of the libicu package. It wouldn't work even when installing from Ubuntu repositories or following one of the official MS installation guides.
When I installed .NET Core 3.1 SDK as described here, it worked by installing all the dependencies correctly: https://docs.microsoft.com/en-us/windows-server/administration/linux-package-repository-for-microsoft-software
As a workaround I've created my own Dockerfile that installs the .NET SDK correctly for Debian 9, then everything worked fine. I will attach the Dockerfile here if anyone is interested.
Thank you!
[JENKINS-64093] .NET Core 3.1 builds fail if SDK is automatically installed from microsoft.com
Shahin Dohan
created issue -
Tim Van Holder
added a comment - I'm also not sure what I can do here. If anything, it's a Microsoft bug. The plugin is installing the package they claim will work on x64 linux. If there are dependencies, it's beyond the scope of what I can do (I can't assume I'm able to run sudo, nor do I intend to add support for N distinct package managers; plus, running system-wide package installs may clash with other builds on the node).
Tim Van Holder
added a comment - I'm also not sure what I can do here. If anything, it's a Microsoft bug. The plugin is installing the package they claim will work on x64 linux. If there are dependencies, it's beyond the scope of what I can do (I can't assume I'm able to run sudo, nor do I intend to add support for N distinct package managers; plus, running system-wide package installs may clash with other builds on the node). 
Shahin Dohan
added a comment - zastai Thank you for the answer Tim, I was also thinking that it's not really possible for you to do much about this. If I were maintaining this, I wouldn't want to support a million different package managers either. I wasn't sure how this plugin does the installations, but can't say I was really expecting direct Debian support.
I already kinda thought this was Microsoft's fault but I went ahead and created the ticket anyway thinking maybe you could do something about it, sorry about that! Let's hope they fix this soon, as it's also happening with .NET 5.
Thanks for the plugin work! 
Shahin Dohan
added a comment - zastai Thank you for the answer Tim, I was also thinking that it's not really possible for you to do much about this. If I were maintaining this, I wouldn't want to support a million different package managers either. I wasn't sure how this plugin does the installations, but can't say I was really expecting direct Debian support.
I already kinda thought this was Microsoft's fault but I went ahead and created the ticket anyway thinking maybe you could do something about it, sorry about that! Let's hope they fix this soon, as it's also happening with .NET 5.
Thanks for the plugin work! Shahin Dohan
made changes -
| Resolution | New: Not A Defect [ 7 ] | |
| Status | Original: Open [ 1 ] | New: Fixed but Unreleased [ 10203 ] |
Shahin Dohan
made changes -
| Status | Original: Fixed but Unreleased [ 10203 ] | New: Closed [ 6 ] |
Shahin Dohan
made changes -
| Comment | [ Microsoft's fault ] |
Tim Van Holder
added a comment - Just tried a clean, core Ubuntu 18 netinstall in a VM, and that starts out with libicu60 installed (as dependency for ubuntu-standard, among others), so I guess it'll be on all Ubuntu 18 machines.
Similarly, on both Debian 9 and 10, libicu is a dependency of shared-mime-info (among others), which gets installed with a minimal system.
I had to explicitly apt-get remove the libicuNN package to reproduce the error.
So on those at least, not having ICU available seems unusual.
Tim Van Holder
added a comment - Just tried a clean, core Ubuntu 18 netinstall in a VM, and that starts out with libicu60 installed (as dependency for ubuntu-standard, among others), so I guess it'll be on all Ubuntu 18 machines.
Similarly, on both Debian 9 and 10, libicu is a dependency of shared-mime-info (among others), which gets installed with a minimal system.
I had to explicitly apt-get remove the libicuNN package to reproduce the error.
So on those at least, not having ICU available seems unusual. 
Microsoft used to offer binaries for various specific distributions; now they have only generic linux, for various architectures. The advantage is: fewer distinct packages; the drawback is that those involve a certain set of prerequisites.
These are unfortunately not specifically documented (even https://docs.microsoft.com/en-gb/dotnet/core/install/linux-debian#manual-install does not mention anything other than extracting the packages), so I can't put that info in the tool installer page.
The plugin is there specifically to avoid having to install stuff machine-wide, as your dockerfile does; I would recommend limiting the setup to installing the .NET Core prerequisites (i.e. libicu in this case, it would seem) specifically.
If you're going to be using docker anyway, it may be more useful to spin up one of Microsoft's .NET SDK images as build agent, rather than running builds on Jenkins' main node.