run writingsystem tests against dotnet 8

[hahn-kev]

There's a bug when using SIL.WritingSystems from a dotnet 8 app, but only when you explicitly reference icu.net from that app.

This PR adds a test to expose that issue, while also fixing it by updating the icu.net version. Since this is a dotnet 8 specific issue it also runs the SIL.WritingSystems tests against dotnet 8

Issue explanation: sillsdev/icu-dotnet#202

this replaces PR #1330 which was made on a fork

---

This change is 

[hahn-kev]

It looks like a lot of our WritingSystem tests (especially related to sorting) are not expecting dotnet 8 to use ICU natively. To resolve this I went ahead and used a configuration flag so that instead of dotnet using ICU it will use NLS which is what .Net Framework uses, this meets the expectations of our tests. That said many of these tests may be over specified, so we should consider if we want to change them or not.

[github-actions]

LibPalaso Tests

   18 files  +    1     18 suites  +1   8m 43s ⏱️ - 4m 32s
4 886 tests +    3  4 655 ✅ +    3  231 💤 ± 0  0 ❌ ±0 
6 331 runs  +1 429  6 047 ✅ +1 389  284 💤 +40  0 ❌ ±0 

Results for commit 880fe0a. ± Comparison against base commit 269c813.

♻️ This comment has been updated with latest results.

[jasonleenaylor]

SIL.WritingSystems/CultureInfoExtensions.cs line 15 at r3 (raw file):

			// Source: https://stackoverflow.com/a/71388328/1964319
			return cultureInfo.CultureTypes.HasFlag(CultureTypes.UserCustomCulture) &&
			       cultureInfo.ThreeLetterWindowsLanguageName == "ZZZ";

So this behaves correctly on Windows 8, and Windows 7?

[jasonleenaylor]

Reviewed 8 of 8 files at r1, 2 of 2 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @josephmyers)

[hahn-kev]

SIL.WritingSystems/CultureInfoExtensions.cs line 15 at r3 (raw file):

Previously, jasonleenaylor (Jason Naylor) wrote…

So this behaves correctly on Windows 8, and Windows 7?

from my testing on windows 7 the CultureInfo constructor throws if you try to use an unknown culture, so yeah this will work on windows 7 I suppose since you can't have an invalid instance.

[hahn-kev]

@ermshiperete can you see why appveyor is failing? The error looks like it's trying to use dotnet 5, however according to https://www.appveyor.com/docs/windows-images-software/ the Visual Studio 2019 image has dotnet 8 installed, and I can't see anywhere that we've hardcoded dotnet 5 in our build scripts. Addtionally using msbuild on Palaso.proj works fine locally, even when I set CI to true.

[ermshiperete]

@ermshiperete can you see why appveyor is failing? The error looks like it's trying to use dotnet 5, however according to https://www.appveyor.com/docs/windows-images-software/ the Visual Studio 2019 image has dotnet 8 installed, and I can't see anywhere that we've hardcoded dotnet 5 in our build scripts. Addtionally using msbuild on Palaso.proj works fine locally, even when I set CI to true.

appveyor.yml specifies "Visual Studio 2019". If I use that locally the build fails with the same error. With VS 2022 things work for me locally.

[rmunn]

appveyor.yml specifies "Visual Studio 2019". If I use that locally the build fails with the same error. With VS 2022 things work for me locally.

Ditto. Their docs say that the Visual Studio 2019 image includes the .NET 8 SDK, but in practice I've found that that's false and you need the 2022 image in order for .NET 8 to work. See sillsdev/flexbridge#407 for example.

[jasonleenaylor]

Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @josephmyers)

[josephmyers]

Reviewed 1 of 1 files at r4, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @hahn-kev)

---

SIL.WritingSystems/CultureInfoExtensions.cs line 15 at r3 (raw file):

Previously, hahn-kev (Kevin Hahn) wrote…

from my testing on windows 7 the CultureInfo constructor throws if you try to use an unknown culture, so yeah this will work on windows 7 I suppose since you can't have an invalid instance.

We did the same thing [in L10nSharp], for reference (sillsdev/l10nsharp#118)