Core: Couldn't find a valid ICU package installed on the system?

[olavt]

I have been running a .NET Core 2.2 application in a Docker container fine on Raspberry PI 3 (using Raspbian Stretch Lite November 2018) with no problems for several weeks.

But, today when trying to run a newly built container I get:

FailFast:
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.

at System.Environment.FailFast(System.String)
at System.Globalization.GlobalizationMode.GetGlobalizationInvariantMode()
at System.Globalization.GlobalizationMode..cctor()
at System.Globalization.CultureData.CreateCultureWithInvariantData()
at System.Globalization.CultureData.get_Invariant()
at System.Globalization.CultureInfo..cctor()
at System.StringComparer..cctor()
at System.AppDomain.InitializeCompatibilityFlags()
at System.AppDomain.CreateAppDomainManager()
at System.AppDomain.Setup(System.Object)

This is my Dockerfile:

FROM microsoft/dotnet:2.2-runtime-stretch-slim-arm32v7
WORKDIR /app
COPY bin/Debug/netcoreapp2.2/linux-arm/publish .
ENTRYPOINT ["dotnet", "NesoyaController.dll"]

[karelz]

Looks like this documented problem based on quick internet search: https://github.com/dotnet/core/blob/master/Documentation/build-and-install-rhel6-prerequisites.md#troubleshooting

[olavt]

How can the article you quoted be relevant to running .NET Core 2.2 in a Docker container using the Microsoft provided base image? Shouldn't the Docker image run with all the dependencies included on the Docker host? As I understand the above article is relevant for installing directly on the OS.

[karelz]

Does the Docket image contain the libraries referenced in the article? Given that Docker images try to be as small as possible (esp. --slim variants - see Docker repo), I wouldn't be surprised if that's the case ...
Either way, I assumed, the docs are enough to point in the right direction. Is that not the case? If not, what is unclear or missing?

[olavt]

I have been running .NET Core application in Docker images over the past 12 months without this kind of problems. Why should it surface out of the blue?

[olavt]

The image runs fine one another Raspberry PI 3 (using the OS image and components), so I suspect that something have went wrong with the platform the Docker image runs on.

[karelz]

I was about to suggest that I can see 4 possible reasons:

1. Change in OS,
2. Change in Docker image used,
3. Change in the app, or
4. The app took different code path.

Looks like you narrowed it down to option 1.

[andrewwebber]

I have just experienced this issue when trying to run a self contained dotnet core application on CoreOS Container Linux, without a Docker container.

E.g.

dotnet publish -c Release -o out -r linux-x64
tar -xcvzf out.gz ./out
scp ...
extract ...
run binary

For me this means that self contained publish output still has some dependencies which might need clarification.

[denniske]

Same issue here. Deployed self contained application into google/cloud-sdk:slim.

[andrewwebber]

My workaround was to edit the generated runtimeconfig.json after following this documentation
https://github.com/dotnet/core/blob/master/Documentation/build-and-install-rhel6-prerequisites.md

{
    "runtimeOptions": {
        "configProperties": {
            "System.Globalization.Invariant": true
        },
    }
}

[denniske]

This solved my problem. Instead of modifying the generated runtimeconfig.json, I created a runtimeconfig.template.json in the project folder which is used automatically by dotnet publish to generate the runtimeconfig.json:

{
    "configProperties": {
        "System.Globalization.Invariant": true
    }
}

[WimTenBrink]

A bit late but I tried my first Linux console application using the Linux subsystem for Windows. Using Debian, Ubuntu and Arch Linux, I discovered that one of these had exactly the same issue! Adding configProperties made it work for all three! Thanks!

[ClientIco]

I can also confirm that the runtimeconfig.template.json when compiling fixes the problem. But it ain't Ideal. I ran unto above mentioned problem while creating my own alpine docker container.

[tmtiwari]

But it ain't Ideal.

When running on Linux, ICU is used to get the time zone display name. In Invariant Mode, the standard time zone names are returned instead. It appears that CentOS 7 is not including "libicu" as well which is required to run dotnetcore.

[alabrashJr]

Derviş Kayımbaşıoğlu's solution is also working.

[jabbalaci]

I had the same issue on Ubuntu 20.04. This trick worked for me:

$ export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1

Tip from here.

[petrsvihlik]

adding <RuntimeHostConfigurationOption Include="System.Globalization.Invariant" Value="true" /> to the csproj worked for me