microsoft / icu Goto Github PK

Description:
I've encountered an issue where the ICU (International Components for Unicode) DLLs from version 64 appear to be incompatible with the data files from ICU version 68. According to the documentation, these versions should be compatible. This incompatibility is causing problems in my application, as it relies on the interoperability of these components.

Steps to Reproduce:

Install ICU version 64 and integrate the DLLs into the application.
Upgrade the ICU data files to version 68.
Run the application and observe the compatibility issue.
Expected Behavior:
The ICU 64 DLLs should be compatible with the ICU 68 data files, allowing for smooth operation of the application.

I would appreciate any insights or solutions to resolve this compatibility issue. Thank you.

Found an issue with en-AU cultulreinfo on win10 (dotnet/runtime#73837) porting a library from net 4.x to 6.x.
Current release is outdated (current version is ICU 71) and windows update seems to ignore new ICU releases.

An updated release of this package can fix the odd behavior of the linked issue.

This might be a duplicate of #120 but the entire library doesn't need to be updated in order to update timezone information, only the timezone resource files. I'm unsure how this is shipped so I could be incorrect on this.

I started creating a custom tzdb using libicu directly for use with date/tz, similar to how STL does it for std::chrono and ended up with a hard realization that the TZ database included with the version of libicu shipped on Windows is over 2 years out of date at this point, shipping with version 2021a of the IANA database.

So my question is straight forward, is this library meant to be used as a reliable TZ database for Windows?

• If not, could I be redirected on what the appropriate way to go about this on Windows is?
• If so, is it okay that the TZ data is 2 years out of date? If it's problematic, could I request the database be updated more regularly, even if the core libicu is not kept up-to-date with upstream?
• Am I even in the right place to request any of this? I feel like a lost child if I'm honest.

References:

• Raymond Chen appears to claim that the globalization team recommends not using Windows identifiers except for legacy cases.

Somewhat Related:

• HowardHinnant/date#771 (comment)

BinSkim (https://github.com/microsoft/binskim) with the Microsoft recommended ruleset flags the native ICU DLLs built as part of the NuGet packages with BA2008: EnableControlFlowGuard.

'icuin72.dll' does not enable the control flow guard (CFG) mitigation. To resolve this issue, pass /guard:cf on both the compiler and linker command lines. Binaries also require the /DYNAMICBASE linker option in order to enable CFG.
'icuuc72.dll' does not enable the control flow guard (CFG) mitigation. To resolve this issue, pass /guard:cf on both the compiler and linker command lines. Binaries also require the /DYNAMICBASE linker option in order to enable CFG.

While using ICU.dll provide by windows, observed that internally x86 builds refer to the x64 icu.dll and vice versa. Is there any work around or fix for this ?

Thanks to Matt Johnson-Pint for filing the upstream CLDR ticket and creating a PR.

Upstream PR: unicode-org/cldr#1193
Upstream CLDR ticket: https://unicode-org.atlassian.net/browse/CLDR-14653

From the CLDR ticket:
Windows Update released 2021-03-29 added a new time zone "South Sudan Standard Time" which needs to be mapped to "Africa/Juba" in the windowsZones.xml file.

Once this is accepted and merged we should cherry-pick the change into MS-ICU.

The latest version of Microsoft.ICU.ICU4C.Runtime is 68.2.0.9 https://www.nuget.org/packages/Microsoft.ICU.ICU4C.Runtime/68.2.0.9 last update (9/27/2021) but I see ICO new version is 73 https://icu.unicode.org/download/73. Is Microsoft.ICU.ICU4C.Runtime is still maintained or I am missing something?

Problem:
The CultureInfo "nb" and "nn" have no parent.
new CultureInfo("nb").Parent / new CultureInfo("nn").Parent return InvariantCulture
Expected:
The CultureInfo "nb" and "nn" have parent "no" .

This is an icu issue and is already fix by following PRs.
unicode-org/cldr#1031
unicode-org/icu#1581

I see MS-ICU 72.1.0.3 contains CLDR 42 so this should be fixed if I use Microsoft.ICU.ICU4C.Runtime 72.1.0.3.
But the actual result is still not fixed.

I added

  <ItemGroup>
    <PackageReference Include="Microsoft.ICU.ICU4C.Runtime.win-x86" Version="72.1.0.3" />
    <RuntimeHostConfigurationOption Include="System.Globalization.AppLocalIcu" Value="72.1.0.3" />
  </ItemGroup>

into the csproj file.

Hello,
Is there any plan to update to ICU 68 (was released a few weeks ago)
http://site.icu-project.org/download/68

Our dotnet/icu fork depends on microsoft/icu.

Hi,
there is wast amount of cultures which are present on Windows 10 and are missing in ICU. What are your plans on getting these two list the same?

Dear all,

when we enabled ICU for our applications, we had a problem with our CI (testhost.exe process was crashed). After deep investigation, we have found that it is not related to our software and problem could be reproduced with simple application.

Steps to reproduce:
add to project file

<ItemGroup>
  <PackageReference Include="Microsoft.ICU.ICU4C.Runtime" Version="68.2.0.9" />
  <RuntimeHostConfigurationOption Include="System.Globalization.AppLocalIcu" Value="68.2.0.9" />
</ItemGroup>

and add to execution code

var locale = CultureInfo.InvariantCulture;
locale.CompareInfo.Compare("Table1", "NewDataSet1", CompareOptions.IgnoreCase | CompareOptions.IgnoreKanaType | CompareOptions.IgnoreWidth);

We are able to reproduce it not on all Windows systems. Even more for some machine it works before without issue and after some updates were installed it crashed now.

We have to created 2 simple application: WPF and Console, and it is reproducible on both of them.
Please find source code here:

• Console app source code: ConsoleStringIssue.zip
• WPF app source code WpfApp2.zip
• Console app crash dump: ConsoleStringIssue.exe_221118_140109.zip
• WPF app crash dump: WpfApp2.exe_221118_144018.dmp.zip

We plan to use System.Globalization.AppLocalIcu with a framework dependent build. That means we can only define this switch once. But as the windows binaries just have the major version as a suffix (file names) and the linux ones have the full version as a suffix, we are not able to use System.Globalization.AppLocalIcu.

The linux release from https://github.com/unicode-org/icu/releases/tag/release-71-1 names the ".so" eg libicuuc.so.71

Any hints?

I recently updated Microsoft.ICU.ICU4C.Runtime from 68.2.0.9 to 72.1.0.1, but my apps then started failing at startup:

Process terminated. Failed to load app-local ICU: icuuc68.2.0.9.dll
   at System.Environment.FailFast(System.String)
   <rest of stack trace omitted>

I checked the NuGet page, and see that the 72 version is described as internal and not for direct dependency:

This surprised me, because the previous version is described as "mature" and "widely used":

Did the nature of Microsoft.ICU.ICU4C.Runtime change? Are we supposed to just never upgrade from 68.2.0.9?