Azure storage is requiring Cultures to be installed instead of using Invariant culture support breaking Dockerized apps etc.

Which service(blob, file, queue, table) does this issue concern?

Blob

Which version of the SDK was used?

Microsoft.Azure.Storage.Blob, Version=10.0.1.0 (which says that it’s Culture-neutral which it isn’t)

Which platform are you using? (ex: .NET Core 2.1)

.NET Core 6 RC 2

What problem was encountered?

The library requires culture info which bloats docker. It shouldn’t need to use anything to do with culture ever.

How can we reproduce the problem in the simplest way?

Simply try to use the option to force .NET to use invariant culture in the csproj.

<RuntimeHostConfigurationOption Include="System.Globalization.Invariant" Value="true" />

Then use the standard calls and you’ll get this error on any call (because it’s in authentication code)

An unhandled exception has occurred while executing the request. Microsoft.Azure.Storage.StorageException: Only the invariant culture is supported in globalization-invariant mode. See https://aka.ms/GlobalizationInvariantMode for more information. (Parameter ‘name’) en-US is an invalid culture identifier. —> System.Globalization.CultureNotFoundException: Only the invariant culture is supported in globalization-invariant mode. See https://aka.ms/GlobalizationInvariantMode for more information. (Parameter ‘name’) en-US is an invalid culture identifier. at System.Globalization.CultureInfo…ctor(String name, Boolean useUserOverride) at Microsoft.Azure.Storage.Core.Util.AuthenticationUtility.AppendCanonicalizedCustomHeaders(CanonicalizedString canonicalizedString, HttpRequestMessage request) at Microsoft.Azure.Storage.Core.Auth.SharedKeyCanonicalizer.CanonicalizeHttpRequest(HttpRequestMessage request, String accountName) at Microsoft.Azure.Storage.Auth.Protocol.StorageAuthenticationHttpHandler.GetSharedKeyAuthenticationTask(StorageRequestMessage request, CancellationToken cancellationToken) at Microsoft.Azure.Storage.Auth.Protocol.StorageAuthenticationHttpHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) at System.Net.Http.HttpMessageInvoker.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken) at Microsoft.Azure.Storage.Core.Executor.Executor.ExecuteAsync[T](RESTCommand1 cmd, IRetryPolicy policy, OperationContext operationContext, CancellationToken token) --- End of inner exception stack trace --- at Microsoft.Azure.Storage.Core.Executor.Executor.ExecuteAsync[T](RESTCommand1 cmd, IRetryPolicy policy, OperationContext operationContext, CancellationToken token

Have you found a mitigation/solution?

Not other than tripling the size of my docker image.

[n8allan]

Correct @JohnGalt1717, it’s a work-around not a solution. I highlighted what I think is the culprit above, and someone should fix it so that the library works with invariant culture, but it would need to be a member of the team that understands why “cannonized headers” are important, and whether or not en-US is actually needed for that purpose.

[n8allan]

For posterity, my work-around was to install the ICU library… sudo apt install libicu-dev … and either remove this from the csproj file (if it’s there):

<ItemGroup>
	<RuntimeHostConfigurationOption Include="System.Globalization.Invariant" Value="true" />
</ItemGroup>

or add this:

<PropertyGroup>
	<InvariantGlobalization>false</InvariantGlobalization>
</PropertyGroup>