dotnet test net8.0 fails on Linux (newline/culture differences)

[fuguiKz]

Repro

On Debian 12 (bookworm) with .NET SDK 10.0.101 (runtimes include Microsoft.NETCore.App 8.0.20) and LANG=en_US.UTF-8, running:

dotnet test tests/CsvHelper.Tests/CsvHelper.Tests.csproj -c Release -f net8.0

on master (33970e5183383bdac1fbce3b3fbcdf46b318ca52) consistently fails with 4 tests.

Failing tests

1. CsvHelper.Tests.TypeConversion.TypeConverterFactoryTests.WriteTypeConverterGenericInt
2. CsvHelper.Tests.TypeConversion.TypeConverterFactoryTests.WriteTypeConverterFactory
   • expected string contains \n, but actual output contains \r\n
3. CsvHelper.Tests.Mappings.ConstructorParameter.CultureInfoAttributeTests.CsvConfiguration_FromType_InvalidAttribute_ThrowsCultureNotFoundException
   • CsvConfiguration.FromAttributes<InvalidAttribute>() does not throw on this environment (seems CultureInfo.GetCultureInfo("invalid") resolves instead of throwing)
4. CsvHelper.Tests.Writing.MultipleFieldsFromOnePropertyTests.WriteMultipleFieldsFromSinglePropertyTest
   • expected 12:00:00 AM (normal space), but actual contains a narrow no-break space before AM (12:00:00\u202FAM)

Notes / hypotheses

• The newline failures look like the test expected is built from a raw string literal whose line endings depend on checkout, while CsvWriter seems to default to CRLF. Maybe build expected via csv.Configuration.NewLine / cw.Configuration.NewLine instead (like other tests).
• The DateTime formatting difference looks like ICU vs Windows NLS culture-data differences for en-US; building expected from DateTime.ToString(culture) or normalizing whitespace could make it platform-neutral.
• The invalid-culture test may need to account for ICU behavior (or use a different invalid culture name that fails consistently).

Happy to open a PR if you'd like any of these adjusted; wanted to check first whether Linux net8.0 test runs are expected to pass.

[fuguiKz]

Extra detail (in case it helps):

• TypeConverterFactoryTests.WriteTypeConverterGenericInt / WriteTypeConverterFactory build expected with a raw string literal (line endings depend on checkout). On my Linux checkout the literal is \n, while CsvWriter output uses CsvConfiguration.NewLine (defaults to \r\n), so Assert.Equal mismatches. Suggest building expected from cw.Configuration.NewLine (or explicitly using \r\n) to make it independent of repo EOL.
• CultureInfoAttributeTests uses [CultureInfo("invalid")]. On ICU it seems CultureInfo.GetCultureInfo("invalid") doesn't throw. A more "guaranteed invalid" name (e.g. containing ! or other invalid chars) should consistently throw on both ICU and Windows NLS.
• MultipleFieldsFromOnePropertyTests hardcodes 12:00:00 AM with a normal space; on ICU the en-US DateTime.ToString(culture) can insert a narrow no-break space (\u202F). Suggest building the expected field via dob.ToString(new CultureInfo("en-US")) (same provider CsvHelper uses) instead of hardcoding.

If you confirm Linux net8.0 runs are expected to pass, I'm happy to open a small PR adjusting only those tests.

[fuguiKz]

Opened PR #2376 to make the failing assertions platform-neutral (tests-only):
#2376

• Uses Configuration.NewLine / TestStringBuilder for expected output (avoids checkout EOL differences).
• Switches the invalid culture name to one that throws consistently on ICU + Windows NLS.
• Builds expected DateTime text via dob.ToString(culture) (handles ICU \u202F).

Local verification (Linux): dotnet test tests/CsvHelper.Tests/CsvHelper.Tests.csproj -c Release -f net8.0 ✅