Options include setting for Culture

[axunonb]

Closes #80

• Serialization and de-serialization can be culture-specific
• Fully compatible with v2.x (using CultureInfo.InvariantCulture as the default setting)
• Limitation: Serialization and de-serialization must use the same culture setting

Breaking changes to v2.x (added CultureInfo parameter):

• ReflectionUtils.ConvertBasicType(object value, Type dstType, CultureInfo culture)
• XMLUtilts.ToXmlValue(this object self, CultureInfo culture)
• XMLUtilts.CreateAttribute(XElement baseElement, string location, XName attrName, object attrValue, XNamespace documentDefaultNamespace, CultureInfo culture)
• XMLUtilts.AddPreserveSpaceAttribute(XElement element, CultureInfo culture)
• XMLUtilts.ToXmlValue(this object self, CultureInfo culture)
• XMLUtilts.AddAttributeNamespaceSafe(this XElement parent, XName attrName, object attrValue, XNamespace documentDefaultNamespace, CultureInfo culture)
• XMLUtilts.AddXmlContent(this XElement self, object contentValue, CultureInfo culture)

Open for discussion:

• Should Exceptions use CultureInfo.InvariantCulture, CultureInfo.CurrentCulture or Options.Culture. The latter is complex with no value IMHO.
• Should utility classes (like mentioned as breaking changes) rather be internal than public?
• Is the Limitation above acceptable? Of course must become part of the docs (know the consequences leaving defaults or alike)

[axunonb]

@304NotModified @NKnusperer Opinion on #139 (comment) appreciated

[304NotModified]

Nice PRs! Will try to review this weekend!

[axunonb]

@304NotModified @NKnusperer
Would be great if you found few minutes for the open for discussion part or review in general ;-)

[304NotModified]

Open for discussion:

• Should Exceptions use CultureInfo.InvariantCulture, CultureInfo.CurrentCulture or Options.Culture. The latter is complex with no value IMHO.

CultureInfo.InvariantCultureorCultureInfo.CurrentCulture` looks good to me.

• Should utility classes (like mentioned as breaking changes) rather be internal than public?

Yes those should be internal

• Is the Limitation above acceptable? Of course must become part of the docs (know the consequences leaving defaults or alike)

Sounds logical to me :)

[304NotModified]

👍 nice

[NKnusperer]

@axunonb I'am in vacation till the end of the week. I will try to catch up next week.

[304NotModified]

@NKnusperer have a good holiday!

[axunonb]

@NKnusperer Hi, hope you some beautiful days off ;-)
Did have a look at #139 (comment) already?
Especially: public classes / methods which had better become internal. A major release were a good opportunity for that, but we have to be careful about the right approach.

[NKnusperer]

Should Exceptions use CultureInfo.InvariantCulture, CultureInfo.CurrentCulture or Options.Culture. The latter is complex with no value IMHO.

With exceptions you're talking about the message?
If so, values that are internally treated as culture-invariant should use CultureInfo.InvariantCulture and vice versa.

Should utility classes (like mentioned as breaking changes) rather be internal than public?

Yes.

Is the Limitation above acceptable? Of course must become part of the docs (know the consequences leaving defaults or alike)

Absolutely.