Tests are failing because I have a different regional settings configured

[janis-veinbergs]

There are like 26 tests failing because I have lv-lv instead of en-us locale.

Sample errors:

   Duration: < 1 ms

  Message: 
Test method Microsoft.Xrm.DevOps.Data.Tests.SchemaImports.MoneyType threw exception: 
System.FormatException: Input string was not in a correct format.

  Stack Trace: 
Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
Number.ParseDecimal(String value, NumberStyles options, NumberFormatInfo numfmt)
Decimal.Parse(String s)
XmlImporter.GetObjectFromFieldNodeType(Field field, Entity schemaData) line 40
DataBuilder.AppendData(Entities DataXML, Entities SchemaXML) line 167
DataBuilder.AppendData(XmlDocument DataXML, XmlDocument SchemaXML) line 144
DataBuilder.AppendData(String DataXML, String SchemaXML) line 131
SchemaImports.MoneyType() line 107
And

  Message: 
Test method Microsoft.Xrm.DevOps.Data.Tests.Configurations.MultipleSourcesOfMetadata_SchemaImported threw exception: 
System.FormatException: String was not recognized as a valid DateTime.

  Stack Trace: 
DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles)
DateTime.Parse(String s)
XmlImporter.GetObjectFromFieldNodeType(Field field, Entity schemaData) line 30
DataBuilder.AppendData(Entities DataXML, Entities SchemaXML) line 167
DataBuilder.AppendData(XmlDocument DataXML, XmlDocument SchemaXML) line 144
DataBuilder.AppendData(String DataXML, String SchemaXML) line 131
Configurations.MultipleSourcesOfMetadata_SchemaImported() line 616

I brought down failing tests to 5 by sprinkling CurrentCulture.InvariantCulture all over the place for ToString or Parse.
However 1 issue remains: DateTime

The DateTimeTypedata.xml contains the following:

 <field name="publishon" value="12/19/2017 4:57:00 PM" />

When I do

FieldNode.Value = Convert.ToString(attribute.Value, CultureInfo.InvariantCulture);

the value is 12/19/2017 16:57:00
And DateTimeType test fails:

    Assert.AreEqual failed. Expected:<<entities xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><entity name="knowledgearticle" displayname="Knowledge Article"><records><record id="6ecdf2da-dae1-e711-9403-0003ff863885"><field name="knowledgearticleid" value="6ecdf2da-dae1-e711-9403-0003ff863885" /><field name="publishon" value="12/19/2017 16:57:00" /></record></records><m2mrelationships /></entity></entities>>. Actual:<<entities xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><entity name="knowledgearticle" displayname="Knowledge Article"><records><record id="6ecdf2da-dae1-e711-9403-0003ff863885"><field name="knowledgearticleid" value="6ecdf2da-dae1-e711-9403-0003ff863885" /><field name="publishon" value="12/19/2017 4:57:00 PM" /></record></records><m2mrelationships /></entity></entities>>. 

My observations during data export using configuration migration tool (as of writing, the latest 9.1.0.110):

• As per my testing the configuration migration tool honors decimal symbol delimiter on data export. That means on export, CurrentCulture should be used.
• The date format stays the same between culture changes: 2023-09-19T12:46:57.0000000Z

So what I propose regarding datetime is the following:

• For all tests wherever dates are used, use the Round trip format specifier 'o' with DateTimeKind.Utc

As for decimals, I don't know. Ofcourse we should leave CurrentCulture whenever someone exports data. However what to do for tessts? Delimiter is hardcoded, but when data gets serialized it uses the currentculture... Probably for tests should override default culture for the whole thread to be InvariantCulture. I hope it can be done in test project and not the .Data project itself.

[janis-veinbergs]

Ok, by setting thread culture for test project, I'm down to 4 failed tests and I don't have to deal with explicitly specifying InvariantCulture for Parse/ToString methods.

[janis-veinbergs]

I'm learning as I go... I thought I'd implement parsing whether decimal is . or , but for some cultures the issue goes farther. When serializing data one would get different formats

For de-DE culture, when it tries to parse decimal like 5.0000000000 (DataImports.DecimalType test), it actually parses it to 50000000000M because it happens to have number group separator as . and decimal separator as ,

So if the xml files happened to be exported with en-US culture, and trying to merge with a de-DE client and mess decimals up.
If doing everything under a single culture, everything should be ok. The issue could arise when developer and devops agent cultures mismatch. The ultimate issue here is that the exported xml doesn't convey the culture it was exported from.

• Implemented support for deserializing dot or comma separated decimals. Added those tests (DotToComma, CommaToDot).
• Adjusted some tests to run under different cultures. In this case I had to provide "alternative" xml data (_comma.xml) which represents numbers in different culture - just as it is when exporting data from CMT (Configuration Migration Tool)