Add Separator property to XmlTextAttribute and XmlAttributeAttribute for configurable list serialization

[Copilot]

[XmlText] string[] has always concatenated array items with no separator (val1val2), while [XmlAttribute] string[] uses space separation (val1 val2). This inconsistency is intentional and tested — changing the default would be breaking. This PR adds an opt-in Separator property to both attributes so users can control the separator character.

API Changes

XmlTextAttribute — new char Separator { get; set; } (default '\0' = no separator, preserves existing concatenation behavior):

// opt-in: space-separated text content, round-trips correctly[XmlText(Separator=' ')]publicstring[]Items{get;set;}// opt-in: comma-separated[XmlText(Separator=',')]publicstring[]Tags{get;set;}

XmlAttributeAttribute — same char Separator { get; set; } (default '\0' = use existing space behavior):

// override attribute separator to comma[XmlAttribute(Separator=',')]publicstring[]Values{get;set;}

'\0' (null char) is the "not set" sentinel — chosen because char? is not valid as a C# attribute argument type (CS0655).

Implementation

• XmlTextAttribute / XmlAttributeAttribute: add char Separator property
• Mappings.cs: add char? Separator to TextAccessor and AttributeAccessor (internal; char? is valid here)
• XmlReflectionImporter: wire attribute → accessor, validate with the internal XmlCharType utility (context-dependent rejection of characters which are not valid for text or attributes; '\0' sentinel skips validation)
• Writers (ReflectionXmlSerializationWriter, XmlSerializationWriter, XmlSerializationWriterILGen): when TextAccessor.Separator.HasValue, emit items with separator between them; for attributes, use Separator ?? ' '
• Readers (ReflectionXmlSerializationReader, XmlSerializationReader, XmlSerializationReaderILGen): when TextAccessor.Separator.HasValue, split text on separator and populate array; uses string.Split(char) overload (not char[]) for IL-gen compatibility
• System.Xml.ReaderWriter ref assembly: updated with new public surface

Backward Compatibility

• [XmlText] string[] with no Separator → unchanged concatenation (val1val2)
• [XmlAttribute] string[] with no Separator override → unchanged space separation (val1 val2)
• Existing test XML_TypeWithXmlTextAttributeOnArray continues to assert val1val2

Original prompt

Context

Issue #115837 reports that [XmlText] string[] on element content serializes array items concatenated without any separator (abcd), while [XmlAttribute] string[] serializes them space-separated (a b c d). This inconsistency has existed since .NET Framework and is the documented/tested behavior — changing the default would be a breaking change.

Design Decision (from discussion with area owner)

Rather than adding a simple IsList boolean, the solution is to add a char? Separator property to both XmlTextAttribute and XmlAttributeAttribute, allowing users to opt into list-style serialization with a configurable separator character.

Key design points:

1. XmlTextAttribute.Separator — defaults to null (meaning no separator, preserving current concatenation behavior of [XmlText] string[]). Setting e.g. Separator = ' ' opts into space-separated list serialization for element text content.

2. XmlAttributeAttribute.Separator — defaults to ' ' (preserving existing space-separated behavior for [XmlAttribute] string[]). Users can override to a different separator if desired.

3. Type should be char? (nullable char), where null means "no separator / use default behavior". This eliminates multi-character separator edge cases and is simple to validate and emit.

4. Validation: Use internal utility XmlCharType on the separator character at reflection/import time (in XmlReflectionImporter).

Implementation Guide

Files that need changes:

Public API surface:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs — Add public char? Separator { get; set; } property (default: null)
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributes.cs — The XmlAttributeAttribute class needs the same public char? Separator { get; set; } property (default: ' ')

Internal mapping infrastructure:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs — TextAccessor is currently an empty class (internal sealed class TextAccessor : Accessor { }). Add an IsList property (or Separator property) mirroring what AttributeAccessor already has with its IsList bool. Consider whether to store the separator char itself or just a bool here.

Reflection import (wiring up the attribute to the mapping):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs — In ImportAccessorMapping, around line 1630-1640, where [XmlText] on array-like types creates a TextAccessor, wire up the separator from the attribute to the accessor. Validate the separator character here using the internal XmlCharType utility. Also around line 1595, where isList is computed for attributes, incorporate the new Separator property from XmlAttributeAttribute.

Serialization writers (emitting the separator during write):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs — In WriteMember, the attribute IsList path already writes " " between values. Add analogous logic for TextAccessor when it has a separator.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs — Similar changes for the non-reflection writer path.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs — IL-gen'd serializer path needs the same logic.

Deserialization readers (splitting on the separator during read):

• The reader paths need to split text content on the separator character when deserializing back to an array. Look at how attribute IsList deserialization currently splits on whitespace and apply similar logic for text content.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs

What NOT to change:

• The existing [XmlAttribute] string[] default behavior must remain space-separated (backward compatible)
• The existing [XmlText] string[] default behavior must remain concatenated with no separator (backward compatible)
• The existing test XML_TypeWithXmlTextAttributeOnArray asserts val1val2 concatenation — this must continue to pass

Tests to add:

• [XmlText(Separator = ' ')] string[] round-trips as space-separated text content
• [XmlText(Separator = ',')] string[] round-trips with comma separation
• [XmlText] string[] (no separa...

This pull request was created from Copilot chat.

Fixes#115837

[Copilot]

Pull request overview

Adds a new Separator option to XmlTextAttribute / XmlAttributeAttribute so XML serializer list-like members can use a caller-chosen delimiter without changing existing defaults.

Changes:

• Adds new public Separator properties to XmlTextAttribute and XmlAttributeAttribute, plus ref assembly updates.
• Threads separator metadata through XmlSerializer mappings/importer and updates reflection, generated-code, and IL-gen reader/writer paths.
• Adds runtime-only serializer tests covering default behavior, custom separators, and separator validation.

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/libraries/System.Xml.ReaderWriter/ref/System.Xml.ReaderWriter.cs	Adds the new public API surface to the ref assembly.
src/libraries/System.Runtime.Serialization.Xml/tests/SerializationTypes.RuntimeOnly.cs	Adds serializer test model types for separator scenarios.
src/libraries/System.Private.Xml/tests/XmlSerializer/XmlSerializerTests.RuntimeOnly.cs	Adds runtime-only XmlSerializer tests for custom separators and validation.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs	Adds XmlTextAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs	Updates IL-generated writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs	Updates source-generated writer paths and adds char literal emission helper.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs	Updates IL-generated reader paths to split on custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs	Updates source-generated reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationGeneratedCode.cs	Exposes the new char-literal helper to generated-code infrastructure.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs	Imports separator metadata and validates separator chars.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributeAttribute.cs	Adds XmlAttributeAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs	Updates reflection-based writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs	Updates reflection-based reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs	Adds separator storage to text/attribute accessors.
src/libraries/System.Private.Xml/src/Resources/Strings.resx	Adds the separator-validation resource string.

[StephenMolloy]

Once code-reviewed within the team, (but before merging of course,) we will go through the API approval process.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated no new comments.

[github-actions]

🤖 Copilot Code Review — PR #126767

Note

This review was generated by Copilot (Claude Opus 4.6) with additional perspectives from Claude Sonnet 4.5. A GPT-5.3-Codex sub-agent was also launched but did not complete within the 10-minute timeout window.

Holistic Assessment

Motivation: The PR addresses a real usability gap — XmlSerializer has no built-in way to control the separator for xs:list-style serialization. The linked issue (#115837) describes a valid scenario where users need non-whitespace separators for array members. The problem is real and the feature is reasonable.

Approach: The approach adds a Separator property (type char, default '\0' as sentinel) to both XmlTextAttribute and XmlAttributeAttribute, threading the value through four distinct serialization code paths (reflection reader/writer, ILGen reader/writer, generated-code reader/writer). The choice of char over char? is forced by C# attribute parameter type restrictions (CS0655). The implementation is thorough — all four paths are updated consistently, validation rejects invalid XML characters, and mixed-content separator tracking is handled correctly.

Summary: ❌ Needs Changes. The implementation quality is solid and the tests are comprehensive, but this PR adds new public API surface without an api-approved issue, which is a blocking requirement in dotnet/runtime. One additional warning is noted below. The code itself appears correct across all serialization paths.

---

Detailed Findings

❌ API Approval — New public API lacks api-approved issue (merge-blocking)

This PR adds two new public properties to the ref assembly (System.Xml.ReaderWriter.cs):

// XmlAttributeAttributepubliccharSeparator{get{thrownull;}set{}}// XmlTextAttributepubliccharSeparator{get{thrownull;}set{}}

The linked issue (#115837) is a bug report with the area-Serialization label only — it has no api-approved, api-ready-for-review, or api-suggestion labels. Per dotnet/runtime API review process, all new public API surface must go through API review and receive the api-approved label before a PR can merge.

Action required: File a formal API proposal issue (or convert #115837) with the proposed API shape, get it through API review with the api-approved label, then link it to this PR. Alternatively, mark both Separator properties as internal pending API review.

Design questions that API review should address:

• Should Separator on XmlAttributeAttribute have ' ' (space) as the default rather than '\0', since space is the current implicit separator?
• How should values containing the separator character be handled? (Raised by @krwq in XML serialization of xs:list elements doesn't respect white-space separation #115837 but never resolved.)
• Is char the right type, or would string? provide more flexibility (e.g., multi-character separators)?

⚠️ Code Quality — [AggressiveInlining] on validation methods (advisory)

In XmlReflectionImporter.cs (lines 2278–2290):

[MethodImpl(MethodImplOptions.AggressiveInlining)]privatestaticvoidValidateTextSeparatorChar(charseparator,stringmemberName){if(!XmlCharType.IsTextChar(separator))thrownewInvalidOperationException(...);}

AggressiveInlining is inappropriate for methods that throw exceptions on the non-fast path. The JIT already handles small methods well, and the attribute can cause the exception-throwing code to be inlined into the caller, bloating the caller's generated code. This contradicts the dotnet/runtime convention of extracting throw helpers into [DoesNotReturn] methods.

These methods are only called during type mapping (not in serialization hot paths), so the performance impact is nil either way — but removing AggressiveInlining would be more consistent with repo conventions.

✅ Correctness — All four serialization paths are consistent

I verified that the separator logic is applied consistently across all code paths:

Path	Writer separator tracking	Reader split logic
Reflection	lastWasText bool, WriteValue(separatorStr)	rawText.Split(separator)
Generated code	lastWasTextVar string variable in emitted code	rawText.Split(charLiteral) emitted
ILGen	lastWasTextLoc LocalBuilder	String.Split(char, StringSplitOptions) IL
Attribute (all paths)	separator ?? ' ' fallback	Split(separator) or Split((char[]?)null)

The ReadContentAsString usage in the ILGen path (vs Reader.ReadString() in generated code) is a pre-existing inconsistency — the original code before this PR already used ReadContentAsString in the ILGen path (the variable was misleadingly named XmlReader_ReadString). This PR correctly renamed it to XmlReader_ReadContentAsString for clarity but did not change the behavior.

✅ Correctness — Mixed-content separator tracking handles nulls correctly

The WriteElements method in ReflectionXmlSerializationWriter.cs correctly handles null items in mixed content:

• When text != null && o is not null: writes text with separator, returns true
• When text != null && o is null: falls through to return emitSeparator (line 313), preserving the separator state without writing anything
• This is verified by the test case "a", null, "b" → "a,b" (no stray separator from null)

✅ Correctness — Default behavior preserved

When Separator is not set ('\0'):

• XmlAttribute: attribute.Separator remains null, falling back to Split((char[]?)null) (whitespace split) and ' ' separator in writers — identical to pre-PR behavior
• XmlText: text.Separator remains null, no split on read, no separator on write — identical to pre-PR behavior (concatenation)

✅ Validation — Correct char validity checks

• ValidateTextSeparatorChar uses XmlCharType.IsTextChar → rejects <, &, ], control chars — correct for text content
• ValidateAttributeSeparatorChar uses XmlCharType.IsAttributeValueChar → additionally rejects ", ', > — correct for attribute values
• The test TypeWithXmlTextSeparatorQuote confirms " is valid as a text separator but invalid as an attribute separator ✅

✅ Test Coverage — Comprehensive

Tests cover: round-trip with comma/space/quote separators, empty strings between separators, single-element arrays, no-separator backward compatibility, invalid separator character rejection, mixed content with elements, null items in mixed content, XmlNode text mapping with separator rejection, and choice-based mixed content.

💡 Suggestion — WriteQuotedCSharpChar could use \u for non-ASCII chars

The WriteQuotedCSharpChar method handles control chars below 32 with \x escapes, but chars between 128-255 could theoretically produce ambiguous \x sequences in generated C# if followed by hex digits. Since validation rejects most problematic chars anyway, this is low risk, but using \u escapes (4-digit, unambiguous) would be more defensive:

<(char)32=> $"\\u{(int)value:X4}",

This is a non-blocking suggestion for robustness.

💡 Observation — Expected.SerializableAssembly.XmlSerializers.cs

The Expected.SerializableAssembly.XmlSerializers.cs file (~5300 lines changed) is a large auto-generated expected-output file that got renumbered because the two new test types shifted all generated method indices by +2. The %%ParentAssemblyId%% placeholder was also restored. This is expected mechanical churn from adding new serializable types.

---

Models contributing: Claude Opus 4.6 (primary), Claude Sonnet 4.5 (sub-agent). GPT-5.3-Codex sub-agent timed out after 10 minutes.

Generated by Code Review for issue #126767 · ◷

[mconnew]

The initial statement:

[XmlAttribute] string[] uses space separation (val1 val2).

Isn't quite right. When reading, it accepts any whitespace character. This includes the typically known tab, form feed, carriage return, new line, and actual space, and any Unicode whitespace. This include unicode codespace of a language which has some more exotic whitespace characters, those are included too. It's conceivable that you want to accept spaces and tabs only, and don't want to allow new lines/carriage returns. Would it be better to have Separator be Separators and a string of characters you want to use for separators?

[mconnew]

The implementation looks good to me based on the intended design. My only feedback is my previous comment, should we be accepting multiple delimiters as the existing functionality already does and this doesn't allow a subset to be used.

[StephenMolloy]

lgtm

[StephenMolloy]

API Proposal for this is #129001

[leculver]

Just one suggestion, but the test file doesn't compile.

[leculver]

Missing a }, so this doesn't compile/run through CI.

[leculver]

I think you also need to escape U+0085/U+2028/U+2029. C# treates these codepoints as newlines:

• U+000D (CR) (handled with \r below)
• U+000A (LF) (handled with \n below)
• U+0085 (NEL)
• U+2028 (LINE SEPARATOR)
• U+2029 (PARAGRAPH SEPARATOR)

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 2 comments.

[Copilot]

[XmlText] string[] has always concatenated array items with no separator (val1val2), while [XmlAttribute] string[] uses space separation (val1 val2). This inconsistency is intentional and tested — changing the default would be breaking. This PR adds an opt-in Separator property to both attributes so users can control the separator character.

API Changes

XmlTextAttribute — new char Separator { get; set; } (default '\0' = no separator, preserves existing concatenation behavior):

// opt-in: space-separated text content, round-trips correctly[XmlText(Separator=' ')]publicstring[]Items{get;set;}// opt-in: comma-separated[XmlText(Separator=',')]publicstring[]Tags{get;set;}

XmlAttributeAttribute — same char Separator { get; set; } (default '\0' = use existing space behavior):

// override attribute separator to comma[XmlAttribute(Separator=',')]publicstring[]Values{get;set;}

'\0' (null char) is the "not set" sentinel — chosen because char? is not valid as a C# attribute argument type (CS0655).

Implementation

• XmlTextAttribute / XmlAttributeAttribute: add char Separator property
• Mappings.cs: add char? Separator to TextAccessor and AttributeAccessor (internal; char? is valid here)
• XmlReflectionImporter: wire attribute → accessor, validate with the internal XmlCharType utility (context-dependent rejection of characters which are not valid for text or attributes; '\0' sentinel skips validation)
• Writers (ReflectionXmlSerializationWriter, XmlSerializationWriter, XmlSerializationWriterILGen): when TextAccessor.Separator.HasValue, emit items with separator between them; for attributes, use Separator ?? ' '
• Readers (ReflectionXmlSerializationReader, XmlSerializationReader, XmlSerializationReaderILGen): when TextAccessor.Separator.HasValue, split text on separator and populate array; uses string.Split(char) overload (not char[]) for IL-gen compatibility
• System.Xml.ReaderWriter ref assembly: updated with new public surface

Backward Compatibility

• [XmlText] string[] with no Separator → unchanged concatenation (val1val2)
• [XmlAttribute] string[] with no Separator override → unchanged space separation (val1 val2)
• Existing test XML_TypeWithXmlTextAttributeOnArray continues to assert val1val2

Original prompt

Context

Issue #115837 reports that [XmlText] string[] on element content serializes array items concatenated without any separator (abcd), while [XmlAttribute] string[] serializes them space-separated (a b c d). This inconsistency has existed since .NET Framework and is the documented/tested behavior — changing the default would be a breaking change.

Design Decision (from discussion with area owner)

Rather than adding a simple IsList boolean, the solution is to add a char? Separator property to both XmlTextAttribute and XmlAttributeAttribute, allowing users to opt into list-style serialization with a configurable separator character.

Key design points:

1. XmlTextAttribute.Separator — defaults to null (meaning no separator, preserving current concatenation behavior of [XmlText] string[]). Setting e.g. Separator = ' ' opts into space-separated list serialization for element text content.

2. XmlAttributeAttribute.Separator — defaults to ' ' (preserving existing space-separated behavior for [XmlAttribute] string[]). Users can override to a different separator if desired.

3. Type should be char? (nullable char), where null means "no separator / use default behavior". This eliminates multi-character separator edge cases and is simple to validate and emit.

4. Validation: Use internal utility XmlCharType on the separator character at reflection/import time (in XmlReflectionImporter).

Implementation Guide

Files that need changes:

Public API surface:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs — Add public char? Separator { get; set; } property (default: null)
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributes.cs — The XmlAttributeAttribute class needs the same public char? Separator { get; set; } property (default: ' ')

Internal mapping infrastructure:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs — TextAccessor is currently an empty class (internal sealed class TextAccessor : Accessor { }). Add an IsList property (or Separator property) mirroring what AttributeAccessor already has with its IsList bool. Consider whether to store the separator char itself or just a bool here.

Reflection import (wiring up the attribute to the mapping):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs — In ImportAccessorMapping, around line 1630-1640, where [XmlText] on array-like types creates a TextAccessor, wire up the separator from the attribute to the accessor. Validate the separator character here using the internal XmlCharType utility. Also around line 1595, where isList is computed for attributes, incorporate the new Separator property from XmlAttributeAttribute.

Serialization writers (emitting the separator during write):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs — In WriteMember, the attribute IsList path already writes " " between values. Add analogous logic for TextAccessor when it has a separator.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs — Similar changes for the non-reflection writer path.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs — IL-gen'd serializer path needs the same logic.

Deserialization readers (splitting on the separator during read):

• The reader paths need to split text content on the separator character when deserializing back to an array. Look at how attribute IsList deserialization currently splits on whitespace and apply similar logic for text content.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs

What NOT to change:

• The existing [XmlAttribute] string[] default behavior must remain space-separated (backward compatible)
• The existing [XmlText] string[] default behavior must remain concatenated with no separator (backward compatible)
• The existing test XML_TypeWithXmlTextAttributeOnArray asserts val1val2 concatenation — this must continue to pass

Tests to add:

• [XmlText(Separator = ' ')] string[] round-trips as space-separated text content
• [XmlText(Separator = ',')] string[] round-trips with comma separation
• [XmlText] string[] (no separa...

This pull request was created from Copilot chat.

Fixes#115837

[Copilot]

Pull request overview

Adds a new Separator option to XmlTextAttribute / XmlAttributeAttribute so XML serializer list-like members can use a caller-chosen delimiter without changing existing defaults.

Changes:

• Adds new public Separator properties to XmlTextAttribute and XmlAttributeAttribute, plus ref assembly updates.
• Threads separator metadata through XmlSerializer mappings/importer and updates reflection, generated-code, and IL-gen reader/writer paths.
• Adds runtime-only serializer tests covering default behavior, custom separators, and separator validation.

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/libraries/System.Xml.ReaderWriter/ref/System.Xml.ReaderWriter.cs	Adds the new public API surface to the ref assembly.
src/libraries/System.Runtime.Serialization.Xml/tests/SerializationTypes.RuntimeOnly.cs	Adds serializer test model types for separator scenarios.
src/libraries/System.Private.Xml/tests/XmlSerializer/XmlSerializerTests.RuntimeOnly.cs	Adds runtime-only XmlSerializer tests for custom separators and validation.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs	Adds XmlTextAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs	Updates IL-generated writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs	Updates source-generated writer paths and adds char literal emission helper.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs	Updates IL-generated reader paths to split on custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs	Updates source-generated reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationGeneratedCode.cs	Exposes the new char-literal helper to generated-code infrastructure.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs	Imports separator metadata and validates separator chars.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributeAttribute.cs	Adds XmlAttributeAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs	Updates reflection-based writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs	Updates reflection-based reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs	Adds separator storage to text/attribute accessors.
src/libraries/System.Private.Xml/src/Resources/Strings.resx	Adds the separator-validation resource string.

[StephenMolloy]

Once code-reviewed within the team, (but before merging of course,) we will go through the API approval process.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated no new comments.

[github-actions]

🤖 Copilot Code Review — PR #126767

Note

This review was generated by Copilot (Claude Opus 4.6) with additional perspectives from Claude Sonnet 4.5. A GPT-5.3-Codex sub-agent was also launched but did not complete within the 10-minute timeout window.

Holistic Assessment

Motivation: The PR addresses a real usability gap — XmlSerializer has no built-in way to control the separator for xs:list-style serialization. The linked issue (#115837) describes a valid scenario where users need non-whitespace separators for array members. The problem is real and the feature is reasonable.

Approach: The approach adds a Separator property (type char, default '\0' as sentinel) to both XmlTextAttribute and XmlAttributeAttribute, threading the value through four distinct serialization code paths (reflection reader/writer, ILGen reader/writer, generated-code reader/writer). The choice of char over char? is forced by C# attribute parameter type restrictions (CS0655). The implementation is thorough — all four paths are updated consistently, validation rejects invalid XML characters, and mixed-content separator tracking is handled correctly.

Summary: ❌ Needs Changes. The implementation quality is solid and the tests are comprehensive, but this PR adds new public API surface without an api-approved issue, which is a blocking requirement in dotnet/runtime. One additional warning is noted below. The code itself appears correct across all serialization paths.

---

Detailed Findings

❌ API Approval — New public API lacks api-approved issue (merge-blocking)

This PR adds two new public properties to the ref assembly (System.Xml.ReaderWriter.cs):

// XmlAttributeAttributepubliccharSeparator{get{thrownull;}set{}}// XmlTextAttributepubliccharSeparator{get{thrownull;}set{}}

The linked issue (#115837) is a bug report with the area-Serialization label only — it has no api-approved, api-ready-for-review, or api-suggestion labels. Per dotnet/runtime API review process, all new public API surface must go through API review and receive the api-approved label before a PR can merge.

Action required: File a formal API proposal issue (or convert #115837) with the proposed API shape, get it through API review with the api-approved label, then link it to this PR. Alternatively, mark both Separator properties as internal pending API review.

Design questions that API review should address:

• Should Separator on XmlAttributeAttribute have ' ' (space) as the default rather than '\0', since space is the current implicit separator?
• How should values containing the separator character be handled? (Raised by @krwq in XML serialization of xs:list elements doesn't respect white-space separation #115837 but never resolved.)
• Is char the right type, or would string? provide more flexibility (e.g., multi-character separators)?

⚠️ Code Quality — [AggressiveInlining] on validation methods (advisory)

In XmlReflectionImporter.cs (lines 2278–2290):

[MethodImpl(MethodImplOptions.AggressiveInlining)]privatestaticvoidValidateTextSeparatorChar(charseparator,stringmemberName){if(!XmlCharType.IsTextChar(separator))thrownewInvalidOperationException(...);}

AggressiveInlining is inappropriate for methods that throw exceptions on the non-fast path. The JIT already handles small methods well, and the attribute can cause the exception-throwing code to be inlined into the caller, bloating the caller's generated code. This contradicts the dotnet/runtime convention of extracting throw helpers into [DoesNotReturn] methods.

These methods are only called during type mapping (not in serialization hot paths), so the performance impact is nil either way — but removing AggressiveInlining would be more consistent with repo conventions.

✅ Correctness — All four serialization paths are consistent

I verified that the separator logic is applied consistently across all code paths:

Path	Writer separator tracking	Reader split logic
Reflection	lastWasText bool, WriteValue(separatorStr)	rawText.Split(separator)
Generated code	lastWasTextVar string variable in emitted code	rawText.Split(charLiteral) emitted
ILGen	lastWasTextLoc LocalBuilder	String.Split(char, StringSplitOptions) IL
Attribute (all paths)	separator ?? ' ' fallback	Split(separator) or Split((char[]?)null)

The ReadContentAsString usage in the ILGen path (vs Reader.ReadString() in generated code) is a pre-existing inconsistency — the original code before this PR already used ReadContentAsString in the ILGen path (the variable was misleadingly named XmlReader_ReadString). This PR correctly renamed it to XmlReader_ReadContentAsString for clarity but did not change the behavior.

✅ Correctness — Mixed-content separator tracking handles nulls correctly

The WriteElements method in ReflectionXmlSerializationWriter.cs correctly handles null items in mixed content:

• When text != null && o is not null: writes text with separator, returns true
• When text != null && o is null: falls through to return emitSeparator (line 313), preserving the separator state without writing anything
• This is verified by the test case "a", null, "b" → "a,b" (no stray separator from null)

✅ Correctness — Default behavior preserved

When Separator is not set ('\0'):

• XmlAttribute: attribute.Separator remains null, falling back to Split((char[]?)null) (whitespace split) and ' ' separator in writers — identical to pre-PR behavior
• XmlText: text.Separator remains null, no split on read, no separator on write — identical to pre-PR behavior (concatenation)

✅ Validation — Correct char validity checks

• ValidateTextSeparatorChar uses XmlCharType.IsTextChar → rejects <, &, ], control chars — correct for text content
• ValidateAttributeSeparatorChar uses XmlCharType.IsAttributeValueChar → additionally rejects ", ', > — correct for attribute values
• The test TypeWithXmlTextSeparatorQuote confirms " is valid as a text separator but invalid as an attribute separator ✅

✅ Test Coverage — Comprehensive

Tests cover: round-trip with comma/space/quote separators, empty strings between separators, single-element arrays, no-separator backward compatibility, invalid separator character rejection, mixed content with elements, null items in mixed content, XmlNode text mapping with separator rejection, and choice-based mixed content.

💡 Suggestion — WriteQuotedCSharpChar could use \u for non-ASCII chars

The WriteQuotedCSharpChar method handles control chars below 32 with \x escapes, but chars between 128-255 could theoretically produce ambiguous \x sequences in generated C# if followed by hex digits. Since validation rejects most problematic chars anyway, this is low risk, but using \u escapes (4-digit, unambiguous) would be more defensive:

<(char)32=> $"\\u{(int)value:X4}",

This is a non-blocking suggestion for robustness.

💡 Observation — Expected.SerializableAssembly.XmlSerializers.cs

The Expected.SerializableAssembly.XmlSerializers.cs file (~5300 lines changed) is a large auto-generated expected-output file that got renumbered because the two new test types shifted all generated method indices by +2. The %%ParentAssemblyId%% placeholder was also restored. This is expected mechanical churn from adding new serializable types.

---

Models contributing: Claude Opus 4.6 (primary), Claude Sonnet 4.5 (sub-agent). GPT-5.3-Codex sub-agent timed out after 10 minutes.

Generated by Code Review for issue #126767 · ◷

[mconnew]

The initial statement:

[XmlAttribute] string[] uses space separation (val1 val2).

Isn't quite right. When reading, it accepts any whitespace character. This includes the typically known tab, form feed, carriage return, new line, and actual space, and any Unicode whitespace. This include unicode codespace of a language which has some more exotic whitespace characters, those are included too. It's conceivable that you want to accept spaces and tabs only, and don't want to allow new lines/carriage returns. Would it be better to have Separator be Separators and a string of characters you want to use for separators?

[mconnew]

The implementation looks good to me based on the intended design. My only feedback is my previous comment, should we be accepting multiple delimiters as the existing functionality already does and this doesn't allow a subset to be used.

[StephenMolloy]

lgtm

[StephenMolloy]

API Proposal for this is #129001

[leculver]

Just one suggestion, but the test file doesn't compile.

[leculver]

Missing a }, so this doesn't compile/run through CI.

[leculver]

I think you also need to escape U+0085/U+2028/U+2029. C# treates these codepoints as newlines:

• U+000D (CR) (handled with \r below)
• U+000A (LF) (handled with \n below)
• U+0085 (NEL)
• U+2028 (LINE SEPARATOR)
• U+2029 (PARAGRAPH SEPARATOR)

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 2 comments.

[Copilot]

[XmlText] string[] has always concatenated array items with no separator (val1val2), while [XmlAttribute] string[] uses space separation (val1 val2). This inconsistency is intentional and tested — changing the default would be breaking. This PR adds an opt-in Separator property to both attributes so users can control the separator character.

API Changes

XmlTextAttribute — new char Separator { get; set; } (default '\0' = no separator, preserves existing concatenation behavior):

// opt-in: space-separated text content, round-trips correctly[XmlText(Separator=' ')]publicstring[]Items{get;set;}// opt-in: comma-separated[XmlText(Separator=',')]publicstring[]Tags{get;set;}

XmlAttributeAttribute — same char Separator { get; set; } (default '\0' = use existing space behavior):

// override attribute separator to comma[XmlAttribute(Separator=',')]publicstring[]Values{get;set;}

'\0' (null char) is the "not set" sentinel — chosen because char? is not valid as a C# attribute argument type (CS0655).

Implementation

• XmlTextAttribute / XmlAttributeAttribute: add char Separator property
• Mappings.cs: add char? Separator to TextAccessor and AttributeAccessor (internal; char? is valid here)
• XmlReflectionImporter: wire attribute → accessor, validate with the internal XmlCharType utility (context-dependent rejection of characters which are not valid for text or attributes; '\0' sentinel skips validation)
• Writers (ReflectionXmlSerializationWriter, XmlSerializationWriter, XmlSerializationWriterILGen): when TextAccessor.Separator.HasValue, emit items with separator between them; for attributes, use Separator ?? ' '
• Readers (ReflectionXmlSerializationReader, XmlSerializationReader, XmlSerializationReaderILGen): when TextAccessor.Separator.HasValue, split text on separator and populate array; uses string.Split(char) overload (not char[]) for IL-gen compatibility
• System.Xml.ReaderWriter ref assembly: updated with new public surface

Backward Compatibility

• [XmlText] string[] with no Separator → unchanged concatenation (val1val2)
• [XmlAttribute] string[] with no Separator override → unchanged space separation (val1 val2)
• Existing test XML_TypeWithXmlTextAttributeOnArray continues to assert val1val2

Original prompt

Context

Issue #115837 reports that [XmlText] string[] on element content serializes array items concatenated without any separator (abcd), while [XmlAttribute] string[] serializes them space-separated (a b c d). This inconsistency has existed since .NET Framework and is the documented/tested behavior — changing the default would be a breaking change.

Design Decision (from discussion with area owner)

Rather than adding a simple IsList boolean, the solution is to add a char? Separator property to both XmlTextAttribute and XmlAttributeAttribute, allowing users to opt into list-style serialization with a configurable separator character.

Key design points:

1. XmlTextAttribute.Separator — defaults to null (meaning no separator, preserving current concatenation behavior of [XmlText] string[]). Setting e.g. Separator = ' ' opts into space-separated list serialization for element text content.

2. XmlAttributeAttribute.Separator — defaults to ' ' (preserving existing space-separated behavior for [XmlAttribute] string[]). Users can override to a different separator if desired.

3. Type should be char? (nullable char), where null means "no separator / use default behavior". This eliminates multi-character separator edge cases and is simple to validate and emit.

4. Validation: Use internal utility XmlCharType on the separator character at reflection/import time (in XmlReflectionImporter).

Implementation Guide

Files that need changes:

Public API surface:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs — Add public char? Separator { get; set; } property (default: null)
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributes.cs — The XmlAttributeAttribute class needs the same public char? Separator { get; set; } property (default: ' ')

Internal mapping infrastructure:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs — TextAccessor is currently an empty class (internal sealed class TextAccessor : Accessor { }). Add an IsList property (or Separator property) mirroring what AttributeAccessor already has with its IsList bool. Consider whether to store the separator char itself or just a bool here.

Reflection import (wiring up the attribute to the mapping):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs — In ImportAccessorMapping, around line 1630-1640, where [XmlText] on array-like types creates a TextAccessor, wire up the separator from the attribute to the accessor. Validate the separator character here using the internal XmlCharType utility. Also around line 1595, where isList is computed for attributes, incorporate the new Separator property from XmlAttributeAttribute.

Serialization writers (emitting the separator during write):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs — In WriteMember, the attribute IsList path already writes " " between values. Add analogous logic for TextAccessor when it has a separator.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs — Similar changes for the non-reflection writer path.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs — IL-gen'd serializer path needs the same logic.

Deserialization readers (splitting on the separator during read):

• The reader paths need to split text content on the separator character when deserializing back to an array. Look at how attribute IsList deserialization currently splits on whitespace and apply similar logic for text content.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs

What NOT to change:

• The existing [XmlAttribute] string[] default behavior must remain space-separated (backward compatible)
• The existing [XmlText] string[] default behavior must remain concatenated with no separator (backward compatible)
• The existing test XML_TypeWithXmlTextAttributeOnArray asserts val1val2 concatenation — this must continue to pass

Tests to add:

• [XmlText(Separator = ' ')] string[] round-trips as space-separated text content
• [XmlText(Separator = ',')] string[] round-trips with comma separation
• [XmlText] string[] (no separa...

This pull request was created from Copilot chat.

Fixes#115837

[Copilot]

Pull request overview

Adds a new Separator option to XmlTextAttribute / XmlAttributeAttribute so XML serializer list-like members can use a caller-chosen delimiter without changing existing defaults.

Changes:

• Adds new public Separator properties to XmlTextAttribute and XmlAttributeAttribute, plus ref assembly updates.
• Threads separator metadata through XmlSerializer mappings/importer and updates reflection, generated-code, and IL-gen reader/writer paths.
• Adds runtime-only serializer tests covering default behavior, custom separators, and separator validation.

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/libraries/System.Xml.ReaderWriter/ref/System.Xml.ReaderWriter.cs	Adds the new public API surface to the ref assembly.
src/libraries/System.Runtime.Serialization.Xml/tests/SerializationTypes.RuntimeOnly.cs	Adds serializer test model types for separator scenarios.
src/libraries/System.Private.Xml/tests/XmlSerializer/XmlSerializerTests.RuntimeOnly.cs	Adds runtime-only XmlSerializer tests for custom separators and validation.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs	Adds XmlTextAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs	Updates IL-generated writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs	Updates source-generated writer paths and adds char literal emission helper.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs	Updates IL-generated reader paths to split on custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs	Updates source-generated reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationGeneratedCode.cs	Exposes the new char-literal helper to generated-code infrastructure.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs	Imports separator metadata and validates separator chars.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributeAttribute.cs	Adds XmlAttributeAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs	Updates reflection-based writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs	Updates reflection-based reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs	Adds separator storage to text/attribute accessors.
src/libraries/System.Private.Xml/src/Resources/Strings.resx	Adds the separator-validation resource string.

[StephenMolloy]

Once code-reviewed within the team, (but before merging of course,) we will go through the API approval process.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated no new comments.

[github-actions]

🤖 Copilot Code Review — PR #126767

Note

This review was generated by Copilot (Claude Opus 4.6) with additional perspectives from Claude Sonnet 4.5. A GPT-5.3-Codex sub-agent was also launched but did not complete within the 10-minute timeout window.

Holistic Assessment

Motivation: The PR addresses a real usability gap — XmlSerializer has no built-in way to control the separator for xs:list-style serialization. The linked issue (#115837) describes a valid scenario where users need non-whitespace separators for array members. The problem is real and the feature is reasonable.

Approach: The approach adds a Separator property (type char, default '\0' as sentinel) to both XmlTextAttribute and XmlAttributeAttribute, threading the value through four distinct serialization code paths (reflection reader/writer, ILGen reader/writer, generated-code reader/writer). The choice of char over char? is forced by C# attribute parameter type restrictions (CS0655). The implementation is thorough — all four paths are updated consistently, validation rejects invalid XML characters, and mixed-content separator tracking is handled correctly.

Summary: ❌ Needs Changes. The implementation quality is solid and the tests are comprehensive, but this PR adds new public API surface without an api-approved issue, which is a blocking requirement in dotnet/runtime. One additional warning is noted below. The code itself appears correct across all serialization paths.

---

Detailed Findings

❌ API Approval — New public API lacks api-approved issue (merge-blocking)

This PR adds two new public properties to the ref assembly (System.Xml.ReaderWriter.cs):

// XmlAttributeAttributepubliccharSeparator{get{thrownull;}set{}}// XmlTextAttributepubliccharSeparator{get{thrownull;}set{}}

The linked issue (#115837) is a bug report with the area-Serialization label only — it has no api-approved, api-ready-for-review, or api-suggestion labels. Per dotnet/runtime API review process, all new public API surface must go through API review and receive the api-approved label before a PR can merge.

Action required: File a formal API proposal issue (or convert #115837) with the proposed API shape, get it through API review with the api-approved label, then link it to this PR. Alternatively, mark both Separator properties as internal pending API review.

Design questions that API review should address:

• Should Separator on XmlAttributeAttribute have ' ' (space) as the default rather than '\0', since space is the current implicit separator?
• How should values containing the separator character be handled? (Raised by @krwq in XML serialization of xs:list elements doesn't respect white-space separation #115837 but never resolved.)
• Is char the right type, or would string? provide more flexibility (e.g., multi-character separators)?

⚠️ Code Quality — [AggressiveInlining] on validation methods (advisory)

In XmlReflectionImporter.cs (lines 2278–2290):

[MethodImpl(MethodImplOptions.AggressiveInlining)]privatestaticvoidValidateTextSeparatorChar(charseparator,stringmemberName){if(!XmlCharType.IsTextChar(separator))thrownewInvalidOperationException(...);}

AggressiveInlining is inappropriate for methods that throw exceptions on the non-fast path. The JIT already handles small methods well, and the attribute can cause the exception-throwing code to be inlined into the caller, bloating the caller's generated code. This contradicts the dotnet/runtime convention of extracting throw helpers into [DoesNotReturn] methods.

These methods are only called during type mapping (not in serialization hot paths), so the performance impact is nil either way — but removing AggressiveInlining would be more consistent with repo conventions.

✅ Correctness — All four serialization paths are consistent

I verified that the separator logic is applied consistently across all code paths:

Path	Writer separator tracking	Reader split logic
Reflection	lastWasText bool, WriteValue(separatorStr)	rawText.Split(separator)
Generated code	lastWasTextVar string variable in emitted code	rawText.Split(charLiteral) emitted
ILGen	lastWasTextLoc LocalBuilder	String.Split(char, StringSplitOptions) IL
Attribute (all paths)	separator ?? ' ' fallback	Split(separator) or Split((char[]?)null)

The ReadContentAsString usage in the ILGen path (vs Reader.ReadString() in generated code) is a pre-existing inconsistency — the original code before this PR already used ReadContentAsString in the ILGen path (the variable was misleadingly named XmlReader_ReadString). This PR correctly renamed it to XmlReader_ReadContentAsString for clarity but did not change the behavior.

✅ Correctness — Mixed-content separator tracking handles nulls correctly

The WriteElements method in ReflectionXmlSerializationWriter.cs correctly handles null items in mixed content:

• When text != null && o is not null: writes text with separator, returns true
• When text != null && o is null: falls through to return emitSeparator (line 313), preserving the separator state without writing anything
• This is verified by the test case "a", null, "b" → "a,b" (no stray separator from null)

✅ Correctness — Default behavior preserved

When Separator is not set ('\0'):

• XmlAttribute: attribute.Separator remains null, falling back to Split((char[]?)null) (whitespace split) and ' ' separator in writers — identical to pre-PR behavior
• XmlText: text.Separator remains null, no split on read, no separator on write — identical to pre-PR behavior (concatenation)

✅ Validation — Correct char validity checks

• ValidateTextSeparatorChar uses XmlCharType.IsTextChar → rejects <, &, ], control chars — correct for text content
• ValidateAttributeSeparatorChar uses XmlCharType.IsAttributeValueChar → additionally rejects ", ', > — correct for attribute values
• The test TypeWithXmlTextSeparatorQuote confirms " is valid as a text separator but invalid as an attribute separator ✅

✅ Test Coverage — Comprehensive

Tests cover: round-trip with comma/space/quote separators, empty strings between separators, single-element arrays, no-separator backward compatibility, invalid separator character rejection, mixed content with elements, null items in mixed content, XmlNode text mapping with separator rejection, and choice-based mixed content.

💡 Suggestion — WriteQuotedCSharpChar could use \u for non-ASCII chars

The WriteQuotedCSharpChar method handles control chars below 32 with \x escapes, but chars between 128-255 could theoretically produce ambiguous \x sequences in generated C# if followed by hex digits. Since validation rejects most problematic chars anyway, this is low risk, but using \u escapes (4-digit, unambiguous) would be more defensive:

<(char)32=> $"\\u{(int)value:X4}",

This is a non-blocking suggestion for robustness.

💡 Observation — Expected.SerializableAssembly.XmlSerializers.cs

The Expected.SerializableAssembly.XmlSerializers.cs file (~5300 lines changed) is a large auto-generated expected-output file that got renumbered because the two new test types shifted all generated method indices by +2. The %%ParentAssemblyId%% placeholder was also restored. This is expected mechanical churn from adding new serializable types.

---

Models contributing: Claude Opus 4.6 (primary), Claude Sonnet 4.5 (sub-agent). GPT-5.3-Codex sub-agent timed out after 10 minutes.

Generated by Code Review for issue #126767 · ◷

[mconnew]

The initial statement:

[XmlAttribute] string[] uses space separation (val1 val2).

Isn't quite right. When reading, it accepts any whitespace character. This includes the typically known tab, form feed, carriage return, new line, and actual space, and any Unicode whitespace. This include unicode codespace of a language which has some more exotic whitespace characters, those are included too. It's conceivable that you want to accept spaces and tabs only, and don't want to allow new lines/carriage returns. Would it be better to have Separator be Separators and a string of characters you want to use for separators?

[mconnew]

The implementation looks good to me based on the intended design. My only feedback is my previous comment, should we be accepting multiple delimiters as the existing functionality already does and this doesn't allow a subset to be used.

[StephenMolloy]

lgtm

[StephenMolloy]

API Proposal for this is #129001

[leculver]

Just one suggestion, but the test file doesn't compile.

[leculver]

Missing a }, so this doesn't compile/run through CI.

[leculver]

I think you also need to escape U+0085/U+2028/U+2029. C# treates these codepoints as newlines:

• U+000D (CR) (handled with \r below)
• U+000A (LF) (handled with \n below)
• U+0085 (NEL)
• U+2028 (LINE SEPARATOR)
• U+2029 (PARAGRAPH SEPARATOR)

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 2 comments.

[Copilot]

[XmlText] string[] has always concatenated array items with no separator (val1val2), while [XmlAttribute] string[] uses space separation (val1 val2). This inconsistency is intentional and tested — changing the default would be breaking. This PR adds an opt-in Separator property to both attributes so users can control the separator character.

API Changes

XmlTextAttribute — new char Separator { get; set; } (default '\0' = no separator, preserves existing concatenation behavior):

// opt-in: space-separated text content, round-trips correctly[XmlText(Separator=' ')]publicstring[]Items{get;set;}// opt-in: comma-separated[XmlText(Separator=',')]publicstring[]Tags{get;set;}

XmlAttributeAttribute — same char Separator { get; set; } (default '\0' = use existing space behavior):

// override attribute separator to comma[XmlAttribute(Separator=',')]publicstring[]Values{get;set;}

'\0' (null char) is the "not set" sentinel — chosen because char? is not valid as a C# attribute argument type (CS0655).

Implementation

• XmlTextAttribute / XmlAttributeAttribute: add char Separator property
• Mappings.cs: add char? Separator to TextAccessor and AttributeAccessor (internal; char? is valid here)
• XmlReflectionImporter: wire attribute → accessor, validate with the internal XmlCharType utility (context-dependent rejection of characters which are not valid for text or attributes; '\0' sentinel skips validation)
• Writers (ReflectionXmlSerializationWriter, XmlSerializationWriter, XmlSerializationWriterILGen): when TextAccessor.Separator.HasValue, emit items with separator between them; for attributes, use Separator ?? ' '
• Readers (ReflectionXmlSerializationReader, XmlSerializationReader, XmlSerializationReaderILGen): when TextAccessor.Separator.HasValue, split text on separator and populate array; uses string.Split(char) overload (not char[]) for IL-gen compatibility
• System.Xml.ReaderWriter ref assembly: updated with new public surface

Backward Compatibility

• [XmlText] string[] with no Separator → unchanged concatenation (val1val2)
• [XmlAttribute] string[] with no Separator override → unchanged space separation (val1 val2)
• Existing test XML_TypeWithXmlTextAttributeOnArray continues to assert val1val2

Original prompt

Context

Issue #115837 reports that [XmlText] string[] on element content serializes array items concatenated without any separator (abcd), while [XmlAttribute] string[] serializes them space-separated (a b c d). This inconsistency has existed since .NET Framework and is the documented/tested behavior — changing the default would be a breaking change.

Design Decision (from discussion with area owner)

Rather than adding a simple IsList boolean, the solution is to add a char? Separator property to both XmlTextAttribute and XmlAttributeAttribute, allowing users to opt into list-style serialization with a configurable separator character.

Key design points:

1. XmlTextAttribute.Separator — defaults to null (meaning no separator, preserving current concatenation behavior of [XmlText] string[]). Setting e.g. Separator = ' ' opts into space-separated list serialization for element text content.

2. XmlAttributeAttribute.Separator — defaults to ' ' (preserving existing space-separated behavior for [XmlAttribute] string[]). Users can override to a different separator if desired.

3. Type should be char? (nullable char), where null means "no separator / use default behavior". This eliminates multi-character separator edge cases and is simple to validate and emit.

4. Validation: Use internal utility XmlCharType on the separator character at reflection/import time (in XmlReflectionImporter).

Implementation Guide

Files that need changes:

Public API surface:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs — Add public char? Separator { get; set; } property (default: null)
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributes.cs — The XmlAttributeAttribute class needs the same public char? Separator { get; set; } property (default: ' ')

Internal mapping infrastructure:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs — TextAccessor is currently an empty class (internal sealed class TextAccessor : Accessor { }). Add an IsList property (or Separator property) mirroring what AttributeAccessor already has with its IsList bool. Consider whether to store the separator char itself or just a bool here.

Reflection import (wiring up the attribute to the mapping):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs — In ImportAccessorMapping, around line 1630-1640, where [XmlText] on array-like types creates a TextAccessor, wire up the separator from the attribute to the accessor. Validate the separator character here using the internal XmlCharType utility. Also around line 1595, where isList is computed for attributes, incorporate the new Separator property from XmlAttributeAttribute.

Serialization writers (emitting the separator during write):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs — In WriteMember, the attribute IsList path already writes " " between values. Add analogous logic for TextAccessor when it has a separator.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs — Similar changes for the non-reflection writer path.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs — IL-gen'd serializer path needs the same logic.

Deserialization readers (splitting on the separator during read):

• The reader paths need to split text content on the separator character when deserializing back to an array. Look at how attribute IsList deserialization currently splits on whitespace and apply similar logic for text content.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs

What NOT to change:

• The existing [XmlAttribute] string[] default behavior must remain space-separated (backward compatible)
• The existing [XmlText] string[] default behavior must remain concatenated with no separator (backward compatible)
• The existing test XML_TypeWithXmlTextAttributeOnArray asserts val1val2 concatenation — this must continue to pass

Tests to add:

• [XmlText(Separator = ' ')] string[] round-trips as space-separated text content
• [XmlText(Separator = ',')] string[] round-trips with comma separation
• [XmlText] string[] (no separa...

This pull request was created from Copilot chat.

Fixes#115837

[Copilot]

Pull request overview

Adds a new Separator option to XmlTextAttribute / XmlAttributeAttribute so XML serializer list-like members can use a caller-chosen delimiter without changing existing defaults.

Changes:

• Adds new public Separator properties to XmlTextAttribute and XmlAttributeAttribute, plus ref assembly updates.
• Threads separator metadata through XmlSerializer mappings/importer and updates reflection, generated-code, and IL-gen reader/writer paths.
• Adds runtime-only serializer tests covering default behavior, custom separators, and separator validation.

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/libraries/System.Xml.ReaderWriter/ref/System.Xml.ReaderWriter.cs	Adds the new public API surface to the ref assembly.
src/libraries/System.Runtime.Serialization.Xml/tests/SerializationTypes.RuntimeOnly.cs	Adds serializer test model types for separator scenarios.
src/libraries/System.Private.Xml/tests/XmlSerializer/XmlSerializerTests.RuntimeOnly.cs	Adds runtime-only XmlSerializer tests for custom separators and validation.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs	Adds XmlTextAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs	Updates IL-generated writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs	Updates source-generated writer paths and adds char literal emission helper.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs	Updates IL-generated reader paths to split on custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs	Updates source-generated reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationGeneratedCode.cs	Exposes the new char-literal helper to generated-code infrastructure.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs	Imports separator metadata and validates separator chars.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributeAttribute.cs	Adds XmlAttributeAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs	Updates reflection-based writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs	Updates reflection-based reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs	Adds separator storage to text/attribute accessors.
src/libraries/System.Private.Xml/src/Resources/Strings.resx	Adds the separator-validation resource string.

[StephenMolloy]

Once code-reviewed within the team, (but before merging of course,) we will go through the API approval process.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated no new comments.

[github-actions]

🤖 Copilot Code Review — PR #126767

Note

This review was generated by Copilot (Claude Opus 4.6) with additional perspectives from Claude Sonnet 4.5. A GPT-5.3-Codex sub-agent was also launched but did not complete within the 10-minute timeout window.

Holistic Assessment

Motivation: The PR addresses a real usability gap — XmlSerializer has no built-in way to control the separator for xs:list-style serialization. The linked issue (#115837) describes a valid scenario where users need non-whitespace separators for array members. The problem is real and the feature is reasonable.

Approach: The approach adds a Separator property (type char, default '\0' as sentinel) to both XmlTextAttribute and XmlAttributeAttribute, threading the value through four distinct serialization code paths (reflection reader/writer, ILGen reader/writer, generated-code reader/writer). The choice of char over char? is forced by C# attribute parameter type restrictions (CS0655). The implementation is thorough — all four paths are updated consistently, validation rejects invalid XML characters, and mixed-content separator tracking is handled correctly.

Summary: ❌ Needs Changes. The implementation quality is solid and the tests are comprehensive, but this PR adds new public API surface without an api-approved issue, which is a blocking requirement in dotnet/runtime. One additional warning is noted below. The code itself appears correct across all serialization paths.

---

Detailed Findings

❌ API Approval — New public API lacks api-approved issue (merge-blocking)

This PR adds two new public properties to the ref assembly (System.Xml.ReaderWriter.cs):

// XmlAttributeAttributepubliccharSeparator{get{thrownull;}set{}}// XmlTextAttributepubliccharSeparator{get{thrownull;}set{}}

The linked issue (#115837) is a bug report with the area-Serialization label only — it has no api-approved, api-ready-for-review, or api-suggestion labels. Per dotnet/runtime API review process, all new public API surface must go through API review and receive the api-approved label before a PR can merge.

Action required: File a formal API proposal issue (or convert #115837) with the proposed API shape, get it through API review with the api-approved label, then link it to this PR. Alternatively, mark both Separator properties as internal pending API review.

Design questions that API review should address:

• Should Separator on XmlAttributeAttribute have ' ' (space) as the default rather than '\0', since space is the current implicit separator?
• How should values containing the separator character be handled? (Raised by @krwq in XML serialization of xs:list elements doesn't respect white-space separation #115837 but never resolved.)
• Is char the right type, or would string? provide more flexibility (e.g., multi-character separators)?

⚠️ Code Quality — [AggressiveInlining] on validation methods (advisory)

In XmlReflectionImporter.cs (lines 2278–2290):

[MethodImpl(MethodImplOptions.AggressiveInlining)]privatestaticvoidValidateTextSeparatorChar(charseparator,stringmemberName){if(!XmlCharType.IsTextChar(separator))thrownewInvalidOperationException(...);}

AggressiveInlining is inappropriate for methods that throw exceptions on the non-fast path. The JIT already handles small methods well, and the attribute can cause the exception-throwing code to be inlined into the caller, bloating the caller's generated code. This contradicts the dotnet/runtime convention of extracting throw helpers into [DoesNotReturn] methods.

These methods are only called during type mapping (not in serialization hot paths), so the performance impact is nil either way — but removing AggressiveInlining would be more consistent with repo conventions.

✅ Correctness — All four serialization paths are consistent

I verified that the separator logic is applied consistently across all code paths:

Path	Writer separator tracking	Reader split logic
Reflection	lastWasText bool, WriteValue(separatorStr)	rawText.Split(separator)
Generated code	lastWasTextVar string variable in emitted code	rawText.Split(charLiteral) emitted
ILGen	lastWasTextLoc LocalBuilder	String.Split(char, StringSplitOptions) IL
Attribute (all paths)	separator ?? ' ' fallback	Split(separator) or Split((char[]?)null)

The ReadContentAsString usage in the ILGen path (vs Reader.ReadString() in generated code) is a pre-existing inconsistency — the original code before this PR already used ReadContentAsString in the ILGen path (the variable was misleadingly named XmlReader_ReadString). This PR correctly renamed it to XmlReader_ReadContentAsString for clarity but did not change the behavior.

✅ Correctness — Mixed-content separator tracking handles nulls correctly

The WriteElements method in ReflectionXmlSerializationWriter.cs correctly handles null items in mixed content:

• When text != null && o is not null: writes text with separator, returns true
• When text != null && o is null: falls through to return emitSeparator (line 313), preserving the separator state without writing anything
• This is verified by the test case "a", null, "b" → "a,b" (no stray separator from null)

✅ Correctness — Default behavior preserved

When Separator is not set ('\0'):

• XmlAttribute: attribute.Separator remains null, falling back to Split((char[]?)null) (whitespace split) and ' ' separator in writers — identical to pre-PR behavior
• XmlText: text.Separator remains null, no split on read, no separator on write — identical to pre-PR behavior (concatenation)

✅ Validation — Correct char validity checks

• ValidateTextSeparatorChar uses XmlCharType.IsTextChar → rejects <, &, ], control chars — correct for text content
• ValidateAttributeSeparatorChar uses XmlCharType.IsAttributeValueChar → additionally rejects ", ', > — correct for attribute values
• The test TypeWithXmlTextSeparatorQuote confirms " is valid as a text separator but invalid as an attribute separator ✅

✅ Test Coverage — Comprehensive

Tests cover: round-trip with comma/space/quote separators, empty strings between separators, single-element arrays, no-separator backward compatibility, invalid separator character rejection, mixed content with elements, null items in mixed content, XmlNode text mapping with separator rejection, and choice-based mixed content.

💡 Suggestion — WriteQuotedCSharpChar could use \u for non-ASCII chars

The WriteQuotedCSharpChar method handles control chars below 32 with \x escapes, but chars between 128-255 could theoretically produce ambiguous \x sequences in generated C# if followed by hex digits. Since validation rejects most problematic chars anyway, this is low risk, but using \u escapes (4-digit, unambiguous) would be more defensive:

<(char)32=> $"\\u{(int)value:X4}",

This is a non-blocking suggestion for robustness.

💡 Observation — Expected.SerializableAssembly.XmlSerializers.cs

The Expected.SerializableAssembly.XmlSerializers.cs file (~5300 lines changed) is a large auto-generated expected-output file that got renumbered because the two new test types shifted all generated method indices by +2. The %%ParentAssemblyId%% placeholder was also restored. This is expected mechanical churn from adding new serializable types.

---

Models contributing: Claude Opus 4.6 (primary), Claude Sonnet 4.5 (sub-agent). GPT-5.3-Codex sub-agent timed out after 10 minutes.

Generated by Code Review for issue #126767 · ◷

[mconnew]

The initial statement:

[XmlAttribute] string[] uses space separation (val1 val2).

Isn't quite right. When reading, it accepts any whitespace character. This includes the typically known tab, form feed, carriage return, new line, and actual space, and any Unicode whitespace. This include unicode codespace of a language which has some more exotic whitespace characters, those are included too. It's conceivable that you want to accept spaces and tabs only, and don't want to allow new lines/carriage returns. Would it be better to have Separator be Separators and a string of characters you want to use for separators?

[mconnew]

The implementation looks good to me based on the intended design. My only feedback is my previous comment, should we be accepting multiple delimiters as the existing functionality already does and this doesn't allow a subset to be used.

[StephenMolloy]

lgtm

[StephenMolloy]

API Proposal for this is #129001

[leculver]

Just one suggestion, but the test file doesn't compile.

[leculver]

Missing a }, so this doesn't compile/run through CI.

[leculver]

I think you also need to escape U+0085/U+2028/U+2029. C# treates these codepoints as newlines:

• U+000D (CR) (handled with \r below)
• U+000A (LF) (handled with \n below)
• U+0085 (NEL)
• U+2028 (LINE SEPARATOR)
• U+2029 (PARAGRAPH SEPARATOR)

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 2 comments.

[Copilot]

[XmlText] string[] has always concatenated array items with no separator (val1val2), while [XmlAttribute] string[] uses space separation (val1 val2). This inconsistency is intentional and tested — changing the default would be breaking. This PR adds an opt-in Separator property to both attributes so users can control the separator character.

API Changes

XmlTextAttribute — new char Separator { get; set; } (default '\0' = no separator, preserves existing concatenation behavior):

// opt-in: space-separated text content, round-trips correctly[XmlText(Separator=' ')]publicstring[]Items{get;set;}// opt-in: comma-separated[XmlText(Separator=',')]publicstring[]Tags{get;set;}

XmlAttributeAttribute — same char Separator { get; set; } (default '\0' = use existing space behavior):

// override attribute separator to comma[XmlAttribute(Separator=',')]publicstring[]Values{get;set;}

'\0' (null char) is the "not set" sentinel — chosen because char? is not valid as a C# attribute argument type (CS0655).

Implementation

• XmlTextAttribute / XmlAttributeAttribute: add char Separator property
• Mappings.cs: add char? Separator to TextAccessor and AttributeAccessor (internal; char? is valid here)
• XmlReflectionImporter: wire attribute → accessor, validate with the internal XmlCharType utility (context-dependent rejection of characters which are not valid for text or attributes; '\0' sentinel skips validation)
• Writers (ReflectionXmlSerializationWriter, XmlSerializationWriter, XmlSerializationWriterILGen): when TextAccessor.Separator.HasValue, emit items with separator between them; for attributes, use Separator ?? ' '
• Readers (ReflectionXmlSerializationReader, XmlSerializationReader, XmlSerializationReaderILGen): when TextAccessor.Separator.HasValue, split text on separator and populate array; uses string.Split(char) overload (not char[]) for IL-gen compatibility
• System.Xml.ReaderWriter ref assembly: updated with new public surface

Backward Compatibility

• [XmlText] string[] with no Separator → unchanged concatenation (val1val2)
• [XmlAttribute] string[] with no Separator override → unchanged space separation (val1 val2)
• Existing test XML_TypeWithXmlTextAttributeOnArray continues to assert val1val2

Original prompt

Context

Issue #115837 reports that [XmlText] string[] on element content serializes array items concatenated without any separator (abcd), while [XmlAttribute] string[] serializes them space-separated (a b c d). This inconsistency has existed since .NET Framework and is the documented/tested behavior — changing the default would be a breaking change.

Design Decision (from discussion with area owner)

Rather than adding a simple IsList boolean, the solution is to add a char? Separator property to both XmlTextAttribute and XmlAttributeAttribute, allowing users to opt into list-style serialization with a configurable separator character.

Key design points:

1. XmlTextAttribute.Separator — defaults to null (meaning no separator, preserving current concatenation behavior of [XmlText] string[]). Setting e.g. Separator = ' ' opts into space-separated list serialization for element text content.

2. XmlAttributeAttribute.Separator — defaults to ' ' (preserving existing space-separated behavior for [XmlAttribute] string[]). Users can override to a different separator if desired.

3. Type should be char? (nullable char), where null means "no separator / use default behavior". This eliminates multi-character separator edge cases and is simple to validate and emit.

4. Validation: Use internal utility XmlCharType on the separator character at reflection/import time (in XmlReflectionImporter).

Implementation Guide

Files that need changes:

Public API surface:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs — Add public char? Separator { get; set; } property (default: null)
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributes.cs — The XmlAttributeAttribute class needs the same public char? Separator { get; set; } property (default: ' ')

Internal mapping infrastructure:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs — TextAccessor is currently an empty class (internal sealed class TextAccessor : Accessor { }). Add an IsList property (or Separator property) mirroring what AttributeAccessor already has with its IsList bool. Consider whether to store the separator char itself or just a bool here.

Reflection import (wiring up the attribute to the mapping):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs — In ImportAccessorMapping, around line 1630-1640, where [XmlText] on array-like types creates a TextAccessor, wire up the separator from the attribute to the accessor. Validate the separator character here using the internal XmlCharType utility. Also around line 1595, where isList is computed for attributes, incorporate the new Separator property from XmlAttributeAttribute.

Serialization writers (emitting the separator during write):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs — In WriteMember, the attribute IsList path already writes " " between values. Add analogous logic for TextAccessor when it has a separator.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs — Similar changes for the non-reflection writer path.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs — IL-gen'd serializer path needs the same logic.

Deserialization readers (splitting on the separator during read):

• The reader paths need to split text content on the separator character when deserializing back to an array. Look at how attribute IsList deserialization currently splits on whitespace and apply similar logic for text content.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs

What NOT to change:

• The existing [XmlAttribute] string[] default behavior must remain space-separated (backward compatible)
• The existing [XmlText] string[] default behavior must remain concatenated with no separator (backward compatible)
• The existing test XML_TypeWithXmlTextAttributeOnArray asserts val1val2 concatenation — this must continue to pass

Tests to add:

• [XmlText(Separator = ' ')] string[] round-trips as space-separated text content
• [XmlText(Separator = ',')] string[] round-trips with comma separation
• [XmlText] string[] (no separa...

This pull request was created from Copilot chat.

Fixes#115837

[Copilot]

Pull request overview

Adds a new Separator option to XmlTextAttribute / XmlAttributeAttribute so XML serializer list-like members can use a caller-chosen delimiter without changing existing defaults.

Changes:

• Adds new public Separator properties to XmlTextAttribute and XmlAttributeAttribute, plus ref assembly updates.
• Threads separator metadata through XmlSerializer mappings/importer and updates reflection, generated-code, and IL-gen reader/writer paths.
• Adds runtime-only serializer tests covering default behavior, custom separators, and separator validation.

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/libraries/System.Xml.ReaderWriter/ref/System.Xml.ReaderWriter.cs	Adds the new public API surface to the ref assembly.
src/libraries/System.Runtime.Serialization.Xml/tests/SerializationTypes.RuntimeOnly.cs	Adds serializer test model types for separator scenarios.
src/libraries/System.Private.Xml/tests/XmlSerializer/XmlSerializerTests.RuntimeOnly.cs	Adds runtime-only XmlSerializer tests for custom separators and validation.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs	Adds XmlTextAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs	Updates IL-generated writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs	Updates source-generated writer paths and adds char literal emission helper.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs	Updates IL-generated reader paths to split on custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs	Updates source-generated reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationGeneratedCode.cs	Exposes the new char-literal helper to generated-code infrastructure.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs	Imports separator metadata and validates separator chars.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributeAttribute.cs	Adds XmlAttributeAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs	Updates reflection-based writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs	Updates reflection-based reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs	Adds separator storage to text/attribute accessors.
src/libraries/System.Private.Xml/src/Resources/Strings.resx	Adds the separator-validation resource string.

[StephenMolloy]

Once code-reviewed within the team, (but before merging of course,) we will go through the API approval process.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated no new comments.

[github-actions]

🤖 Copilot Code Review — PR #126767

Note

This review was generated by Copilot (Claude Opus 4.6) with additional perspectives from Claude Sonnet 4.5. A GPT-5.3-Codex sub-agent was also launched but did not complete within the 10-minute timeout window.

Holistic Assessment

Motivation: The PR addresses a real usability gap — XmlSerializer has no built-in way to control the separator for xs:list-style serialization. The linked issue (#115837) describes a valid scenario where users need non-whitespace separators for array members. The problem is real and the feature is reasonable.

Approach: The approach adds a Separator property (type char, default '\0' as sentinel) to both XmlTextAttribute and XmlAttributeAttribute, threading the value through four distinct serialization code paths (reflection reader/writer, ILGen reader/writer, generated-code reader/writer). The choice of char over char? is forced by C# attribute parameter type restrictions (CS0655). The implementation is thorough — all four paths are updated consistently, validation rejects invalid XML characters, and mixed-content separator tracking is handled correctly.

Summary: ❌ Needs Changes. The implementation quality is solid and the tests are comprehensive, but this PR adds new public API surface without an api-approved issue, which is a blocking requirement in dotnet/runtime. One additional warning is noted below. The code itself appears correct across all serialization paths.

---

Detailed Findings

❌ API Approval — New public API lacks api-approved issue (merge-blocking)

This PR adds two new public properties to the ref assembly (System.Xml.ReaderWriter.cs):

// XmlAttributeAttributepubliccharSeparator{get{thrownull;}set{}}// XmlTextAttributepubliccharSeparator{get{thrownull;}set{}}

The linked issue (#115837) is a bug report with the area-Serialization label only — it has no api-approved, api-ready-for-review, or api-suggestion labels. Per dotnet/runtime API review process, all new public API surface must go through API review and receive the api-approved label before a PR can merge.

Action required: File a formal API proposal issue (or convert #115837) with the proposed API shape, get it through API review with the api-approved label, then link it to this PR. Alternatively, mark both Separator properties as internal pending API review.

Design questions that API review should address:

• Should Separator on XmlAttributeAttribute have ' ' (space) as the default rather than '\0', since space is the current implicit separator?
• How should values containing the separator character be handled? (Raised by @krwq in XML serialization of xs:list elements doesn't respect white-space separation #115837 but never resolved.)
• Is char the right type, or would string? provide more flexibility (e.g., multi-character separators)?

⚠️ Code Quality — [AggressiveInlining] on validation methods (advisory)

In XmlReflectionImporter.cs (lines 2278–2290):

[MethodImpl(MethodImplOptions.AggressiveInlining)]privatestaticvoidValidateTextSeparatorChar(charseparator,stringmemberName){if(!XmlCharType.IsTextChar(separator))thrownewInvalidOperationException(...);}

AggressiveInlining is inappropriate for methods that throw exceptions on the non-fast path. The JIT already handles small methods well, and the attribute can cause the exception-throwing code to be inlined into the caller, bloating the caller's generated code. This contradicts the dotnet/runtime convention of extracting throw helpers into [DoesNotReturn] methods.

These methods are only called during type mapping (not in serialization hot paths), so the performance impact is nil either way — but removing AggressiveInlining would be more consistent with repo conventions.

✅ Correctness — All four serialization paths are consistent

I verified that the separator logic is applied consistently across all code paths:

Path	Writer separator tracking	Reader split logic
Reflection	lastWasText bool, WriteValue(separatorStr)	rawText.Split(separator)
Generated code	lastWasTextVar string variable in emitted code	rawText.Split(charLiteral) emitted
ILGen	lastWasTextLoc LocalBuilder	String.Split(char, StringSplitOptions) IL
Attribute (all paths)	separator ?? ' ' fallback	Split(separator) or Split((char[]?)null)

The ReadContentAsString usage in the ILGen path (vs Reader.ReadString() in generated code) is a pre-existing inconsistency — the original code before this PR already used ReadContentAsString in the ILGen path (the variable was misleadingly named XmlReader_ReadString). This PR correctly renamed it to XmlReader_ReadContentAsString for clarity but did not change the behavior.

✅ Correctness — Mixed-content separator tracking handles nulls correctly

The WriteElements method in ReflectionXmlSerializationWriter.cs correctly handles null items in mixed content:

• When text != null && o is not null: writes text with separator, returns true
• When text != null && o is null: falls through to return emitSeparator (line 313), preserving the separator state without writing anything
• This is verified by the test case "a", null, "b" → "a,b" (no stray separator from null)

✅ Correctness — Default behavior preserved

When Separator is not set ('\0'):

• XmlAttribute: attribute.Separator remains null, falling back to Split((char[]?)null) (whitespace split) and ' ' separator in writers — identical to pre-PR behavior
• XmlText: text.Separator remains null, no split on read, no separator on write — identical to pre-PR behavior (concatenation)

✅ Validation — Correct char validity checks

• ValidateTextSeparatorChar uses XmlCharType.IsTextChar → rejects <, &, ], control chars — correct for text content
• ValidateAttributeSeparatorChar uses XmlCharType.IsAttributeValueChar → additionally rejects ", ', > — correct for attribute values
• The test TypeWithXmlTextSeparatorQuote confirms " is valid as a text separator but invalid as an attribute separator ✅

✅ Test Coverage — Comprehensive

Tests cover: round-trip with comma/space/quote separators, empty strings between separators, single-element arrays, no-separator backward compatibility, invalid separator character rejection, mixed content with elements, null items in mixed content, XmlNode text mapping with separator rejection, and choice-based mixed content.

💡 Suggestion — WriteQuotedCSharpChar could use \u for non-ASCII chars

The WriteQuotedCSharpChar method handles control chars below 32 with \x escapes, but chars between 128-255 could theoretically produce ambiguous \x sequences in generated C# if followed by hex digits. Since validation rejects most problematic chars anyway, this is low risk, but using \u escapes (4-digit, unambiguous) would be more defensive:

<(char)32=> $"\\u{(int)value:X4}",

This is a non-blocking suggestion for robustness.

💡 Observation — Expected.SerializableAssembly.XmlSerializers.cs

The Expected.SerializableAssembly.XmlSerializers.cs file (~5300 lines changed) is a large auto-generated expected-output file that got renumbered because the two new test types shifted all generated method indices by +2. The %%ParentAssemblyId%% placeholder was also restored. This is expected mechanical churn from adding new serializable types.

---

Models contributing: Claude Opus 4.6 (primary), Claude Sonnet 4.5 (sub-agent). GPT-5.3-Codex sub-agent timed out after 10 minutes.

Generated by Code Review for issue #126767 · ◷

[mconnew]

The initial statement:

[XmlAttribute] string[] uses space separation (val1 val2).

Isn't quite right. When reading, it accepts any whitespace character. This includes the typically known tab, form feed, carriage return, new line, and actual space, and any Unicode whitespace. This include unicode codespace of a language which has some more exotic whitespace characters, those are included too. It's conceivable that you want to accept spaces and tabs only, and don't want to allow new lines/carriage returns. Would it be better to have Separator be Separators and a string of characters you want to use for separators?

[mconnew]

The implementation looks good to me based on the intended design. My only feedback is my previous comment, should we be accepting multiple delimiters as the existing functionality already does and this doesn't allow a subset to be used.

[StephenMolloy]

lgtm

[StephenMolloy]

API Proposal for this is #129001

[leculver]

Just one suggestion, but the test file doesn't compile.

[leculver]

Missing a }, so this doesn't compile/run through CI.

[leculver]

I think you also need to escape U+0085/U+2028/U+2029. C# treates these codepoints as newlines:

• U+000D (CR) (handled with \r below)
• U+000A (LF) (handled with \n below)
• U+0085 (NEL)
• U+2028 (LINE SEPARATOR)
• U+2029 (PARAGRAPH SEPARATOR)

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 2 comments.

[Copilot]

[XmlText] string[] has always concatenated array items with no separator (val1val2), while [XmlAttribute] string[] uses space separation (val1 val2). This inconsistency is intentional and tested — changing the default would be breaking. This PR adds an opt-in Separator property to both attributes so users can control the separator character.

API Changes

XmlTextAttribute — new char Separator { get; set; } (default '\0' = no separator, preserves existing concatenation behavior):

// opt-in: space-separated text content, round-trips correctly[XmlText(Separator=' ')]publicstring[]Items{get;set;}// opt-in: comma-separated[XmlText(Separator=',')]publicstring[]Tags{get;set;}

XmlAttributeAttribute — same char Separator { get; set; } (default '\0' = use existing space behavior):

// override attribute separator to comma[XmlAttribute(Separator=',')]publicstring[]Values{get;set;}

'\0' (null char) is the "not set" sentinel — chosen because char? is not valid as a C# attribute argument type (CS0655).

Implementation

• XmlTextAttribute / XmlAttributeAttribute: add char Separator property
• Mappings.cs: add char? Separator to TextAccessor and AttributeAccessor (internal; char? is valid here)
• XmlReflectionImporter: wire attribute → accessor, validate with the internal XmlCharType utility (context-dependent rejection of characters which are not valid for text or attributes; '\0' sentinel skips validation)
• Writers (ReflectionXmlSerializationWriter, XmlSerializationWriter, XmlSerializationWriterILGen): when TextAccessor.Separator.HasValue, emit items with separator between them; for attributes, use Separator ?? ' '
• Readers (ReflectionXmlSerializationReader, XmlSerializationReader, XmlSerializationReaderILGen): when TextAccessor.Separator.HasValue, split text on separator and populate array; uses string.Split(char) overload (not char[]) for IL-gen compatibility
• System.Xml.ReaderWriter ref assembly: updated with new public surface

Backward Compatibility

• [XmlText] string[] with no Separator → unchanged concatenation (val1val2)
• [XmlAttribute] string[] with no Separator override → unchanged space separation (val1 val2)
• Existing test XML_TypeWithXmlTextAttributeOnArray continues to assert val1val2

Original prompt

Context

Issue #115837 reports that [XmlText] string[] on element content serializes array items concatenated without any separator (abcd), while [XmlAttribute] string[] serializes them space-separated (a b c d). This inconsistency has existed since .NET Framework and is the documented/tested behavior — changing the default would be a breaking change.

Design Decision (from discussion with area owner)

Rather than adding a simple IsList boolean, the solution is to add a char? Separator property to both XmlTextAttribute and XmlAttributeAttribute, allowing users to opt into list-style serialization with a configurable separator character.

Key design points:

1. XmlTextAttribute.Separator — defaults to null (meaning no separator, preserving current concatenation behavior of [XmlText] string[]). Setting e.g. Separator = ' ' opts into space-separated list serialization for element text content.

2. XmlAttributeAttribute.Separator — defaults to ' ' (preserving existing space-separated behavior for [XmlAttribute] string[]). Users can override to a different separator if desired.

3. Type should be char? (nullable char), where null means "no separator / use default behavior". This eliminates multi-character separator edge cases and is simple to validate and emit.

4. Validation: Use internal utility XmlCharType on the separator character at reflection/import time (in XmlReflectionImporter).

Implementation Guide

Files that need changes:

Public API surface:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs — Add public char? Separator { get; set; } property (default: null)
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributes.cs — The XmlAttributeAttribute class needs the same public char? Separator { get; set; } property (default: ' ')

Internal mapping infrastructure:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs — TextAccessor is currently an empty class (internal sealed class TextAccessor : Accessor { }). Add an IsList property (or Separator property) mirroring what AttributeAccessor already has with its IsList bool. Consider whether to store the separator char itself or just a bool here.

Reflection import (wiring up the attribute to the mapping):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs — In ImportAccessorMapping, around line 1630-1640, where [XmlText] on array-like types creates a TextAccessor, wire up the separator from the attribute to the accessor. Validate the separator character here using the internal XmlCharType utility. Also around line 1595, where isList is computed for attributes, incorporate the new Separator property from XmlAttributeAttribute.

Serialization writers (emitting the separator during write):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs — In WriteMember, the attribute IsList path already writes " " between values. Add analogous logic for TextAccessor when it has a separator.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs — Similar changes for the non-reflection writer path.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs — IL-gen'd serializer path needs the same logic.

Deserialization readers (splitting on the separator during read):

• The reader paths need to split text content on the separator character when deserializing back to an array. Look at how attribute IsList deserialization currently splits on whitespace and apply similar logic for text content.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs

What NOT to change:

• The existing [XmlAttribute] string[] default behavior must remain space-separated (backward compatible)
• The existing [XmlText] string[] default behavior must remain concatenated with no separator (backward compatible)
• The existing test XML_TypeWithXmlTextAttributeOnArray asserts val1val2 concatenation — this must continue to pass

Tests to add:

• [XmlText(Separator = ' ')] string[] round-trips as space-separated text content
• [XmlText(Separator = ',')] string[] round-trips with comma separation
• [XmlText] string[] (no separa...

This pull request was created from Copilot chat.

Fixes#115837

[Copilot]

Pull request overview

Adds a new Separator option to XmlTextAttribute / XmlAttributeAttribute so XML serializer list-like members can use a caller-chosen delimiter without changing existing defaults.

Changes:

• Adds new public Separator properties to XmlTextAttribute and XmlAttributeAttribute, plus ref assembly updates.
• Threads separator metadata through XmlSerializer mappings/importer and updates reflection, generated-code, and IL-gen reader/writer paths.
• Adds runtime-only serializer tests covering default behavior, custom separators, and separator validation.

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/libraries/System.Xml.ReaderWriter/ref/System.Xml.ReaderWriter.cs	Adds the new public API surface to the ref assembly.
src/libraries/System.Runtime.Serialization.Xml/tests/SerializationTypes.RuntimeOnly.cs	Adds serializer test model types for separator scenarios.
src/libraries/System.Private.Xml/tests/XmlSerializer/XmlSerializerTests.RuntimeOnly.cs	Adds runtime-only XmlSerializer tests for custom separators and validation.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs	Adds XmlTextAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs	Updates IL-generated writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs	Updates source-generated writer paths and adds char literal emission helper.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs	Updates IL-generated reader paths to split on custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs	Updates source-generated reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationGeneratedCode.cs	Exposes the new char-literal helper to generated-code infrastructure.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs	Imports separator metadata and validates separator chars.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributeAttribute.cs	Adds XmlAttributeAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs	Updates reflection-based writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs	Updates reflection-based reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs	Adds separator storage to text/attribute accessors.
src/libraries/System.Private.Xml/src/Resources/Strings.resx	Adds the separator-validation resource string.

[StephenMolloy]

Once code-reviewed within the team, (but before merging of course,) we will go through the API approval process.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated no new comments.

[github-actions]

🤖 Copilot Code Review — PR #126767

Note

This review was generated by Copilot (Claude Opus 4.6) with additional perspectives from Claude Sonnet 4.5. A GPT-5.3-Codex sub-agent was also launched but did not complete within the 10-minute timeout window.

Holistic Assessment

Motivation: The PR addresses a real usability gap — XmlSerializer has no built-in way to control the separator for xs:list-style serialization. The linked issue (#115837) describes a valid scenario where users need non-whitespace separators for array members. The problem is real and the feature is reasonable.

Approach: The approach adds a Separator property (type char, default '\0' as sentinel) to both XmlTextAttribute and XmlAttributeAttribute, threading the value through four distinct serialization code paths (reflection reader/writer, ILGen reader/writer, generated-code reader/writer). The choice of char over char? is forced by C# attribute parameter type restrictions (CS0655). The implementation is thorough — all four paths are updated consistently, validation rejects invalid XML characters, and mixed-content separator tracking is handled correctly.

Summary: ❌ Needs Changes. The implementation quality is solid and the tests are comprehensive, but this PR adds new public API surface without an api-approved issue, which is a blocking requirement in dotnet/runtime. One additional warning is noted below. The code itself appears correct across all serialization paths.

---

Detailed Findings

❌ API Approval — New public API lacks api-approved issue (merge-blocking)

This PR adds two new public properties to the ref assembly (System.Xml.ReaderWriter.cs):

// XmlAttributeAttributepubliccharSeparator{get{thrownull;}set{}}// XmlTextAttributepubliccharSeparator{get{thrownull;}set{}}

The linked issue (#115837) is a bug report with the area-Serialization label only — it has no api-approved, api-ready-for-review, or api-suggestion labels. Per dotnet/runtime API review process, all new public API surface must go through API review and receive the api-approved label before a PR can merge.

Action required: File a formal API proposal issue (or convert #115837) with the proposed API shape, get it through API review with the api-approved label, then link it to this PR. Alternatively, mark both Separator properties as internal pending API review.

Design questions that API review should address:

• Should Separator on XmlAttributeAttribute have ' ' (space) as the default rather than '\0', since space is the current implicit separator?
• How should values containing the separator character be handled? (Raised by @krwq in XML serialization of xs:list elements doesn't respect white-space separation #115837 but never resolved.)
• Is char the right type, or would string? provide more flexibility (e.g., multi-character separators)?

⚠️ Code Quality — [AggressiveInlining] on validation methods (advisory)

In XmlReflectionImporter.cs (lines 2278–2290):

[MethodImpl(MethodImplOptions.AggressiveInlining)]privatestaticvoidValidateTextSeparatorChar(charseparator,stringmemberName){if(!XmlCharType.IsTextChar(separator))thrownewInvalidOperationException(...);}

AggressiveInlining is inappropriate for methods that throw exceptions on the non-fast path. The JIT already handles small methods well, and the attribute can cause the exception-throwing code to be inlined into the caller, bloating the caller's generated code. This contradicts the dotnet/runtime convention of extracting throw helpers into [DoesNotReturn] methods.

These methods are only called during type mapping (not in serialization hot paths), so the performance impact is nil either way — but removing AggressiveInlining would be more consistent with repo conventions.

✅ Correctness — All four serialization paths are consistent

I verified that the separator logic is applied consistently across all code paths:

Path	Writer separator tracking	Reader split logic
Reflection	lastWasText bool, WriteValue(separatorStr)	rawText.Split(separator)
Generated code	lastWasTextVar string variable in emitted code	rawText.Split(charLiteral) emitted
ILGen	lastWasTextLoc LocalBuilder	String.Split(char, StringSplitOptions) IL
Attribute (all paths)	separator ?? ' ' fallback	Split(separator) or Split((char[]?)null)

The ReadContentAsString usage in the ILGen path (vs Reader.ReadString() in generated code) is a pre-existing inconsistency — the original code before this PR already used ReadContentAsString in the ILGen path (the variable was misleadingly named XmlReader_ReadString). This PR correctly renamed it to XmlReader_ReadContentAsString for clarity but did not change the behavior.

✅ Correctness — Mixed-content separator tracking handles nulls correctly

The WriteElements method in ReflectionXmlSerializationWriter.cs correctly handles null items in mixed content:

• When text != null && o is not null: writes text with separator, returns true
• When text != null && o is null: falls through to return emitSeparator (line 313), preserving the separator state without writing anything
• This is verified by the test case "a", null, "b" → "a,b" (no stray separator from null)

✅ Correctness — Default behavior preserved

When Separator is not set ('\0'):

• XmlAttribute: attribute.Separator remains null, falling back to Split((char[]?)null) (whitespace split) and ' ' separator in writers — identical to pre-PR behavior
• XmlText: text.Separator remains null, no split on read, no separator on write — identical to pre-PR behavior (concatenation)

✅ Validation — Correct char validity checks

• ValidateTextSeparatorChar uses XmlCharType.IsTextChar → rejects <, &, ], control chars — correct for text content
• ValidateAttributeSeparatorChar uses XmlCharType.IsAttributeValueChar → additionally rejects ", ', > — correct for attribute values
• The test TypeWithXmlTextSeparatorQuote confirms " is valid as a text separator but invalid as an attribute separator ✅

✅ Test Coverage — Comprehensive

Tests cover: round-trip with comma/space/quote separators, empty strings between separators, single-element arrays, no-separator backward compatibility, invalid separator character rejection, mixed content with elements, null items in mixed content, XmlNode text mapping with separator rejection, and choice-based mixed content.

💡 Suggestion — WriteQuotedCSharpChar could use \u for non-ASCII chars

The WriteQuotedCSharpChar method handles control chars below 32 with \x escapes, but chars between 128-255 could theoretically produce ambiguous \x sequences in generated C# if followed by hex digits. Since validation rejects most problematic chars anyway, this is low risk, but using \u escapes (4-digit, unambiguous) would be more defensive:

<(char)32=> $"\\u{(int)value:X4}",

This is a non-blocking suggestion for robustness.

💡 Observation — Expected.SerializableAssembly.XmlSerializers.cs

The Expected.SerializableAssembly.XmlSerializers.cs file (~5300 lines changed) is a large auto-generated expected-output file that got renumbered because the two new test types shifted all generated method indices by +2. The %%ParentAssemblyId%% placeholder was also restored. This is expected mechanical churn from adding new serializable types.

---

Models contributing: Claude Opus 4.6 (primary), Claude Sonnet 4.5 (sub-agent). GPT-5.3-Codex sub-agent timed out after 10 minutes.

Generated by Code Review for issue #126767 · ◷

[mconnew]

The initial statement:

[XmlAttribute] string[] uses space separation (val1 val2).

Isn't quite right. When reading, it accepts any whitespace character. This includes the typically known tab, form feed, carriage return, new line, and actual space, and any Unicode whitespace. This include unicode codespace of a language which has some more exotic whitespace characters, those are included too. It's conceivable that you want to accept spaces and tabs only, and don't want to allow new lines/carriage returns. Would it be better to have Separator be Separators and a string of characters you want to use for separators?

[mconnew]

The implementation looks good to me based on the intended design. My only feedback is my previous comment, should we be accepting multiple delimiters as the existing functionality already does and this doesn't allow a subset to be used.

[StephenMolloy]

lgtm

[StephenMolloy]

API Proposal for this is #129001

[leculver]

Just one suggestion, but the test file doesn't compile.

[leculver]

Missing a }, so this doesn't compile/run through CI.

[leculver]

I think you also need to escape U+0085/U+2028/U+2029. C# treates these codepoints as newlines:

• U+000D (CR) (handled with \r below)
• U+000A (LF) (handled with \n below)
• U+0085 (NEL)
• U+2028 (LINE SEPARATOR)
• U+2029 (PARAGRAPH SEPARATOR)

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 2 comments.

[Copilot]

[XmlText] string[] has always concatenated array items with no separator (val1val2), while [XmlAttribute] string[] uses space separation (val1 val2). This inconsistency is intentional and tested — changing the default would be breaking. This PR adds an opt-in Separator property to both attributes so users can control the separator character.

API Changes

XmlTextAttribute — new char Separator { get; set; } (default '\0' = no separator, preserves existing concatenation behavior):

// opt-in: space-separated text content, round-trips correctly[XmlText(Separator=' ')]publicstring[]Items{get;set;}// opt-in: comma-separated[XmlText(Separator=',')]publicstring[]Tags{get;set;}

XmlAttributeAttribute — same char Separator { get; set; } (default '\0' = use existing space behavior):

// override attribute separator to comma[XmlAttribute(Separator=',')]publicstring[]Values{get;set;}

'\0' (null char) is the "not set" sentinel — chosen because char? is not valid as a C# attribute argument type (CS0655).

Implementation

• XmlTextAttribute / XmlAttributeAttribute: add char Separator property
• Mappings.cs: add char? Separator to TextAccessor and AttributeAccessor (internal; char? is valid here)
• XmlReflectionImporter: wire attribute → accessor, validate with the internal XmlCharType utility (context-dependent rejection of characters which are not valid for text or attributes; '\0' sentinel skips validation)
• Writers (ReflectionXmlSerializationWriter, XmlSerializationWriter, XmlSerializationWriterILGen): when TextAccessor.Separator.HasValue, emit items with separator between them; for attributes, use Separator ?? ' '
• Readers (ReflectionXmlSerializationReader, XmlSerializationReader, XmlSerializationReaderILGen): when TextAccessor.Separator.HasValue, split text on separator and populate array; uses string.Split(char) overload (not char[]) for IL-gen compatibility
• System.Xml.ReaderWriter ref assembly: updated with new public surface

Backward Compatibility

• [XmlText] string[] with no Separator → unchanged concatenation (val1val2)
• [XmlAttribute] string[] with no Separator override → unchanged space separation (val1 val2)
• Existing test XML_TypeWithXmlTextAttributeOnArray continues to assert val1val2

Original prompt

Context

Issue #115837 reports that [XmlText] string[] on element content serializes array items concatenated without any separator (abcd), while [XmlAttribute] string[] serializes them space-separated (a b c d). This inconsistency has existed since .NET Framework and is the documented/tested behavior — changing the default would be a breaking change.

Design Decision (from discussion with area owner)

Rather than adding a simple IsList boolean, the solution is to add a char? Separator property to both XmlTextAttribute and XmlAttributeAttribute, allowing users to opt into list-style serialization with a configurable separator character.

Key design points:

1. XmlTextAttribute.Separator — defaults to null (meaning no separator, preserving current concatenation behavior of [XmlText] string[]). Setting e.g. Separator = ' ' opts into space-separated list serialization for element text content.

2. XmlAttributeAttribute.Separator — defaults to ' ' (preserving existing space-separated behavior for [XmlAttribute] string[]). Users can override to a different separator if desired.

3. Type should be char? (nullable char), where null means "no separator / use default behavior". This eliminates multi-character separator edge cases and is simple to validate and emit.

4. Validation: Use internal utility XmlCharType on the separator character at reflection/import time (in XmlReflectionImporter).

Implementation Guide

Files that need changes:

Public API surface:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs — Add public char? Separator { get; set; } property (default: null)
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributes.cs — The XmlAttributeAttribute class needs the same public char? Separator { get; set; } property (default: ' ')

Internal mapping infrastructure:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs — TextAccessor is currently an empty class (internal sealed class TextAccessor : Accessor { }). Add an IsList property (or Separator property) mirroring what AttributeAccessor already has with its IsList bool. Consider whether to store the separator char itself or just a bool here.

Reflection import (wiring up the attribute to the mapping):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs — In ImportAccessorMapping, around line 1630-1640, where [XmlText] on array-like types creates a TextAccessor, wire up the separator from the attribute to the accessor. Validate the separator character here using the internal XmlCharType utility. Also around line 1595, where isList is computed for attributes, incorporate the new Separator property from XmlAttributeAttribute.

Serialization writers (emitting the separator during write):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs — In WriteMember, the attribute IsList path already writes " " between values. Add analogous logic for TextAccessor when it has a separator.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs — Similar changes for the non-reflection writer path.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs — IL-gen'd serializer path needs the same logic.

Deserialization readers (splitting on the separator during read):

• The reader paths need to split text content on the separator character when deserializing back to an array. Look at how attribute IsList deserialization currently splits on whitespace and apply similar logic for text content.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs

What NOT to change:

• The existing [XmlAttribute] string[] default behavior must remain space-separated (backward compatible)
• The existing [XmlText] string[] default behavior must remain concatenated with no separator (backward compatible)
• The existing test XML_TypeWithXmlTextAttributeOnArray asserts val1val2 concatenation — this must continue to pass

Tests to add:

• [XmlText(Separator = ' ')] string[] round-trips as space-separated text content
• [XmlText(Separator = ',')] string[] round-trips with comma separation
• [XmlText] string[] (no separa...

This pull request was created from Copilot chat.

Fixes#115837

[Copilot]

Pull request overview

Adds a new Separator option to XmlTextAttribute / XmlAttributeAttribute so XML serializer list-like members can use a caller-chosen delimiter without changing existing defaults.

Changes:

• Adds new public Separator properties to XmlTextAttribute and XmlAttributeAttribute, plus ref assembly updates.
• Threads separator metadata through XmlSerializer mappings/importer and updates reflection, generated-code, and IL-gen reader/writer paths.
• Adds runtime-only serializer tests covering default behavior, custom separators, and separator validation.

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/libraries/System.Xml.ReaderWriter/ref/System.Xml.ReaderWriter.cs	Adds the new public API surface to the ref assembly.
src/libraries/System.Runtime.Serialization.Xml/tests/SerializationTypes.RuntimeOnly.cs	Adds serializer test model types for separator scenarios.
src/libraries/System.Private.Xml/tests/XmlSerializer/XmlSerializerTests.RuntimeOnly.cs	Adds runtime-only XmlSerializer tests for custom separators and validation.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs	Adds XmlTextAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs	Updates IL-generated writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs	Updates source-generated writer paths and adds char literal emission helper.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs	Updates IL-generated reader paths to split on custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs	Updates source-generated reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationGeneratedCode.cs	Exposes the new char-literal helper to generated-code infrastructure.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs	Imports separator metadata and validates separator chars.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributeAttribute.cs	Adds XmlAttributeAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs	Updates reflection-based writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs	Updates reflection-based reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs	Adds separator storage to text/attribute accessors.
src/libraries/System.Private.Xml/src/Resources/Strings.resx	Adds the separator-validation resource string.

[StephenMolloy]

Once code-reviewed within the team, (but before merging of course,) we will go through the API approval process.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated no new comments.

[github-actions]

🤖 Copilot Code Review — PR #126767

Note

This review was generated by Copilot (Claude Opus 4.6) with additional perspectives from Claude Sonnet 4.5. A GPT-5.3-Codex sub-agent was also launched but did not complete within the 10-minute timeout window.

Holistic Assessment

Motivation: The PR addresses a real usability gap — XmlSerializer has no built-in way to control the separator for xs:list-style serialization. The linked issue (#115837) describes a valid scenario where users need non-whitespace separators for array members. The problem is real and the feature is reasonable.

Approach: The approach adds a Separator property (type char, default '\0' as sentinel) to both XmlTextAttribute and XmlAttributeAttribute, threading the value through four distinct serialization code paths (reflection reader/writer, ILGen reader/writer, generated-code reader/writer). The choice of char over char? is forced by C# attribute parameter type restrictions (CS0655). The implementation is thorough — all four paths are updated consistently, validation rejects invalid XML characters, and mixed-content separator tracking is handled correctly.

Summary: ❌ Needs Changes. The implementation quality is solid and the tests are comprehensive, but this PR adds new public API surface without an api-approved issue, which is a blocking requirement in dotnet/runtime. One additional warning is noted below. The code itself appears correct across all serialization paths.

---

Detailed Findings

❌ API Approval — New public API lacks api-approved issue (merge-blocking)

This PR adds two new public properties to the ref assembly (System.Xml.ReaderWriter.cs):

// XmlAttributeAttributepubliccharSeparator{get{thrownull;}set{}}// XmlTextAttributepubliccharSeparator{get{thrownull;}set{}}

The linked issue (#115837) is a bug report with the area-Serialization label only — it has no api-approved, api-ready-for-review, or api-suggestion labels. Per dotnet/runtime API review process, all new public API surface must go through API review and receive the api-approved label before a PR can merge.

Action required: File a formal API proposal issue (or convert #115837) with the proposed API shape, get it through API review with the api-approved label, then link it to this PR. Alternatively, mark both Separator properties as internal pending API review.

Design questions that API review should address:

• Should Separator on XmlAttributeAttribute have ' ' (space) as the default rather than '\0', since space is the current implicit separator?
• How should values containing the separator character be handled? (Raised by @krwq in XML serialization of xs:list elements doesn't respect white-space separation #115837 but never resolved.)
• Is char the right type, or would string? provide more flexibility (e.g., multi-character separators)?

⚠️ Code Quality — [AggressiveInlining] on validation methods (advisory)

In XmlReflectionImporter.cs (lines 2278–2290):

[MethodImpl(MethodImplOptions.AggressiveInlining)]privatestaticvoidValidateTextSeparatorChar(charseparator,stringmemberName){if(!XmlCharType.IsTextChar(separator))thrownewInvalidOperationException(...);}

AggressiveInlining is inappropriate for methods that throw exceptions on the non-fast path. The JIT already handles small methods well, and the attribute can cause the exception-throwing code to be inlined into the caller, bloating the caller's generated code. This contradicts the dotnet/runtime convention of extracting throw helpers into [DoesNotReturn] methods.

These methods are only called during type mapping (not in serialization hot paths), so the performance impact is nil either way — but removing AggressiveInlining would be more consistent with repo conventions.

✅ Correctness — All four serialization paths are consistent

I verified that the separator logic is applied consistently across all code paths:

Path	Writer separator tracking	Reader split logic
Reflection	lastWasText bool, WriteValue(separatorStr)	rawText.Split(separator)
Generated code	lastWasTextVar string variable in emitted code	rawText.Split(charLiteral) emitted
ILGen	lastWasTextLoc LocalBuilder	String.Split(char, StringSplitOptions) IL
Attribute (all paths)	separator ?? ' ' fallback	Split(separator) or Split((char[]?)null)

The ReadContentAsString usage in the ILGen path (vs Reader.ReadString() in generated code) is a pre-existing inconsistency — the original code before this PR already used ReadContentAsString in the ILGen path (the variable was misleadingly named XmlReader_ReadString). This PR correctly renamed it to XmlReader_ReadContentAsString for clarity but did not change the behavior.

✅ Correctness — Mixed-content separator tracking handles nulls correctly

The WriteElements method in ReflectionXmlSerializationWriter.cs correctly handles null items in mixed content:

• When text != null && o is not null: writes text with separator, returns true
• When text != null && o is null: falls through to return emitSeparator (line 313), preserving the separator state without writing anything
• This is verified by the test case "a", null, "b" → "a,b" (no stray separator from null)

✅ Correctness — Default behavior preserved

When Separator is not set ('\0'):

• XmlAttribute: attribute.Separator remains null, falling back to Split((char[]?)null) (whitespace split) and ' ' separator in writers — identical to pre-PR behavior
• XmlText: text.Separator remains null, no split on read, no separator on write — identical to pre-PR behavior (concatenation)

✅ Validation — Correct char validity checks

• ValidateTextSeparatorChar uses XmlCharType.IsTextChar → rejects <, &, ], control chars — correct for text content
• ValidateAttributeSeparatorChar uses XmlCharType.IsAttributeValueChar → additionally rejects ", ', > — correct for attribute values
• The test TypeWithXmlTextSeparatorQuote confirms " is valid as a text separator but invalid as an attribute separator ✅

✅ Test Coverage — Comprehensive

Tests cover: round-trip with comma/space/quote separators, empty strings between separators, single-element arrays, no-separator backward compatibility, invalid separator character rejection, mixed content with elements, null items in mixed content, XmlNode text mapping with separator rejection, and choice-based mixed content.

💡 Suggestion — WriteQuotedCSharpChar could use \u for non-ASCII chars

The WriteQuotedCSharpChar method handles control chars below 32 with \x escapes, but chars between 128-255 could theoretically produce ambiguous \x sequences in generated C# if followed by hex digits. Since validation rejects most problematic chars anyway, this is low risk, but using \u escapes (4-digit, unambiguous) would be more defensive:

<(char)32=> $"\\u{(int)value:X4}",

This is a non-blocking suggestion for robustness.

💡 Observation — Expected.SerializableAssembly.XmlSerializers.cs

The Expected.SerializableAssembly.XmlSerializers.cs file (~5300 lines changed) is a large auto-generated expected-output file that got renumbered because the two new test types shifted all generated method indices by +2. The %%ParentAssemblyId%% placeholder was also restored. This is expected mechanical churn from adding new serializable types.

---

Models contributing: Claude Opus 4.6 (primary), Claude Sonnet 4.5 (sub-agent). GPT-5.3-Codex sub-agent timed out after 10 minutes.

Generated by Code Review for issue #126767 · ◷

[mconnew]

The initial statement:

[XmlAttribute] string[] uses space separation (val1 val2).

Isn't quite right. When reading, it accepts any whitespace character. This includes the typically known tab, form feed, carriage return, new line, and actual space, and any Unicode whitespace. This include unicode codespace of a language which has some more exotic whitespace characters, those are included too. It's conceivable that you want to accept spaces and tabs only, and don't want to allow new lines/carriage returns. Would it be better to have Separator be Separators and a string of characters you want to use for separators?

[mconnew]

The implementation looks good to me based on the intended design. My only feedback is my previous comment, should we be accepting multiple delimiters as the existing functionality already does and this doesn't allow a subset to be used.

[StephenMolloy]

lgtm

[StephenMolloy]

API Proposal for this is #129001

[leculver]

Just one suggestion, but the test file doesn't compile.

[leculver]

Missing a }, so this doesn't compile/run through CI.

[leculver]

I think you also need to escape U+0085/U+2028/U+2029. C# treates these codepoints as newlines:

• U+000D (CR) (handled with \r below)
• U+000A (LF) (handled with \n below)
• U+0085 (NEL)
• U+2028 (LINE SEPARATOR)
• U+2029 (PARAGRAPH SEPARATOR)

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 2 comments.

[Copilot]

[XmlText] string[] has always concatenated array items with no separator (val1val2), while [XmlAttribute] string[] uses space separation (val1 val2). This inconsistency is intentional and tested — changing the default would be breaking. This PR adds an opt-in Separator property to both attributes so users can control the separator character.

API Changes

XmlTextAttribute — new char Separator { get; set; } (default '\0' = no separator, preserves existing concatenation behavior):

// opt-in: space-separated text content, round-trips correctly[XmlText(Separator=' ')]publicstring[]Items{get;set;}// opt-in: comma-separated[XmlText(Separator=',')]publicstring[]Tags{get;set;}

XmlAttributeAttribute — same char Separator { get; set; } (default '\0' = use existing space behavior):

// override attribute separator to comma[XmlAttribute(Separator=',')]publicstring[]Values{get;set;}

'\0' (null char) is the "not set" sentinel — chosen because char? is not valid as a C# attribute argument type (CS0655).

Implementation

• XmlTextAttribute / XmlAttributeAttribute: add char Separator property
• Mappings.cs: add char? Separator to TextAccessor and AttributeAccessor (internal; char? is valid here)
• XmlReflectionImporter: wire attribute → accessor, validate with the internal XmlCharType utility (context-dependent rejection of characters which are not valid for text or attributes; '\0' sentinel skips validation)
• Writers (ReflectionXmlSerializationWriter, XmlSerializationWriter, XmlSerializationWriterILGen): when TextAccessor.Separator.HasValue, emit items with separator between them; for attributes, use Separator ?? ' '
• Readers (ReflectionXmlSerializationReader, XmlSerializationReader, XmlSerializationReaderILGen): when TextAccessor.Separator.HasValue, split text on separator and populate array; uses string.Split(char) overload (not char[]) for IL-gen compatibility
• System.Xml.ReaderWriter ref assembly: updated with new public surface

Backward Compatibility

• [XmlText] string[] with no Separator → unchanged concatenation (val1val2)
• [XmlAttribute] string[] with no Separator override → unchanged space separation (val1 val2)
• Existing test XML_TypeWithXmlTextAttributeOnArray continues to assert val1val2

Original prompt

Context

Issue #115837 reports that [XmlText] string[] on element content serializes array items concatenated without any separator (abcd), while [XmlAttribute] string[] serializes them space-separated (a b c d). This inconsistency has existed since .NET Framework and is the documented/tested behavior — changing the default would be a breaking change.

Design Decision (from discussion with area owner)

Rather than adding a simple IsList boolean, the solution is to add a char? Separator property to both XmlTextAttribute and XmlAttributeAttribute, allowing users to opt into list-style serialization with a configurable separator character.

Key design points:

1. XmlTextAttribute.Separator — defaults to null (meaning no separator, preserving current concatenation behavior of [XmlText] string[]). Setting e.g. Separator = ' ' opts into space-separated list serialization for element text content.

2. XmlAttributeAttribute.Separator — defaults to ' ' (preserving existing space-separated behavior for [XmlAttribute] string[]). Users can override to a different separator if desired.

3. Type should be char? (nullable char), where null means "no separator / use default behavior". This eliminates multi-character separator edge cases and is simple to validate and emit.

4. Validation: Use internal utility XmlCharType on the separator character at reflection/import time (in XmlReflectionImporter).

Implementation Guide

Files that need changes:

Public API surface:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs — Add public char? Separator { get; set; } property (default: null)
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributes.cs — The XmlAttributeAttribute class needs the same public char? Separator { get; set; } property (default: ' ')

Internal mapping infrastructure:

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs — TextAccessor is currently an empty class (internal sealed class TextAccessor : Accessor { }). Add an IsList property (or Separator property) mirroring what AttributeAccessor already has with its IsList bool. Consider whether to store the separator char itself or just a bool here.

Reflection import (wiring up the attribute to the mapping):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs — In ImportAccessorMapping, around line 1630-1640, where [XmlText] on array-like types creates a TextAccessor, wire up the separator from the attribute to the accessor. Validate the separator character here using the internal XmlCharType utility. Also around line 1595, where isList is computed for attributes, incorporate the new Separator property from XmlAttributeAttribute.

Serialization writers (emitting the separator during write):

• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs — In WriteMember, the attribute IsList path already writes " " between values. Add analogous logic for TextAccessor when it has a separator.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs — Similar changes for the non-reflection writer path.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs — IL-gen'd serializer path needs the same logic.

Deserialization readers (splitting on the separator during read):

• The reader paths need to split text content on the separator character when deserializing back to an array. Look at how attribute IsList deserialization currently splits on whitespace and apply similar logic for text content.
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs
• src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs

What NOT to change:

• The existing [XmlAttribute] string[] default behavior must remain space-separated (backward compatible)
• The existing [XmlText] string[] default behavior must remain concatenated with no separator (backward compatible)
• The existing test XML_TypeWithXmlTextAttributeOnArray asserts val1val2 concatenation — this must continue to pass

Tests to add:

• [XmlText(Separator = ' ')] string[] round-trips as space-separated text content
• [XmlText(Separator = ',')] string[] round-trips with comma separation
• [XmlText] string[] (no separa...

This pull request was created from Copilot chat.

Fixes#115837

[Copilot]

Pull request overview

Adds a new Separator option to XmlTextAttribute / XmlAttributeAttribute so XML serializer list-like members can use a caller-chosen delimiter without changing existing defaults.

Changes:

• Adds new public Separator properties to XmlTextAttribute and XmlAttributeAttribute, plus ref assembly updates.
• Threads separator metadata through XmlSerializer mappings/importer and updates reflection, generated-code, and IL-gen reader/writer paths.
• Adds runtime-only serializer tests covering default behavior, custom separators, and separator validation.

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/libraries/System.Xml.ReaderWriter/ref/System.Xml.ReaderWriter.cs	Adds the new public API surface to the ref assembly.
src/libraries/System.Runtime.Serialization.Xml/tests/SerializationTypes.RuntimeOnly.cs	Adds serializer test model types for separator scenarios.
src/libraries/System.Private.Xml/tests/XmlSerializer/XmlSerializerTests.RuntimeOnly.cs	Adds runtime-only XmlSerializer tests for custom separators and validation.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlTextAttribute.cs	Adds XmlTextAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriterILGen.cs	Updates IL-generated writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationWriter.cs	Updates source-generated writer paths and adds char literal emission helper.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReaderILGen.cs	Updates IL-generated reader paths to split on custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationReader.cs	Updates source-generated reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlSerializationGeneratedCode.cs	Exposes the new char-literal helper to generated-code infrastructure.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlReflectionImporter.cs	Imports separator metadata and validates separator chars.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/XmlAttributeAttribute.cs	Adds XmlAttributeAttribute.Separator.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationWriter.cs	Updates reflection-based writer paths for custom separators.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/ReflectionXmlSerializationReader.cs	Updates reflection-based reader paths for custom separator parsing.
src/libraries/System.Private.Xml/src/System/Xml/Serialization/Mappings.cs	Adds separator storage to text/attribute accessors.
src/libraries/System.Private.Xml/src/Resources/Strings.resx	Adds the separator-validation resource string.

[StephenMolloy]

Once code-reviewed within the team, (but before merging of course,) we will go through the API approval process.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated no new comments.

[github-actions]

🤖 Copilot Code Review — PR #126767

Note

This review was generated by Copilot (Claude Opus 4.6) with additional perspectives from Claude Sonnet 4.5. A GPT-5.3-Codex sub-agent was also launched but did not complete within the 10-minute timeout window.

Holistic Assessment

Motivation: The PR addresses a real usability gap — XmlSerializer has no built-in way to control the separator for xs:list-style serialization. The linked issue (#115837) describes a valid scenario where users need non-whitespace separators for array members. The problem is real and the feature is reasonable.

Approach: The approach adds a Separator property (type char, default '\0' as sentinel) to both XmlTextAttribute and XmlAttributeAttribute, threading the value through four distinct serialization code paths (reflection reader/writer, ILGen reader/writer, generated-code reader/writer). The choice of char over char? is forced by C# attribute parameter type restrictions (CS0655). The implementation is thorough — all four paths are updated consistently, validation rejects invalid XML characters, and mixed-content separator tracking is handled correctly.

Summary: ❌ Needs Changes. The implementation quality is solid and the tests are comprehensive, but this PR adds new public API surface without an api-approved issue, which is a blocking requirement in dotnet/runtime. One additional warning is noted below. The code itself appears correct across all serialization paths.

---

Detailed Findings

❌ API Approval — New public API lacks api-approved issue (merge-blocking)

This PR adds two new public properties to the ref assembly (System.Xml.ReaderWriter.cs):

// XmlAttributeAttributepubliccharSeparator{get{thrownull;}set{}}// XmlTextAttributepubliccharSeparator{get{thrownull;}set{}}

The linked issue (#115837) is a bug report with the area-Serialization label only — it has no api-approved, api-ready-for-review, or api-suggestion labels. Per dotnet/runtime API review process, all new public API surface must go through API review and receive the api-approved label before a PR can merge.

Action required: File a formal API proposal issue (or convert #115837) with the proposed API shape, get it through API review with the api-approved label, then link it to this PR. Alternatively, mark both Separator properties as internal pending API review.

Design questions that API review should address:

• Should Separator on XmlAttributeAttribute have ' ' (space) as the default rather than '\0', since space is the current implicit separator?
• How should values containing the separator character be handled? (Raised by @krwq in XML serialization of xs:list elements doesn't respect white-space separation #115837 but never resolved.)
• Is char the right type, or would string? provide more flexibility (e.g., multi-character separators)?

⚠️ Code Quality — [AggressiveInlining] on validation methods (advisory)

In XmlReflectionImporter.cs (lines 2278–2290):

[MethodImpl(MethodImplOptions.AggressiveInlining)]privatestaticvoidValidateTextSeparatorChar(charseparator,stringmemberName){if(!XmlCharType.IsTextChar(separator))thrownewInvalidOperationException(...);}

AggressiveInlining is inappropriate for methods that throw exceptions on the non-fast path. The JIT already handles small methods well, and the attribute can cause the exception-throwing code to be inlined into the caller, bloating the caller's generated code. This contradicts the dotnet/runtime convention of extracting throw helpers into [DoesNotReturn] methods.

These methods are only called during type mapping (not in serialization hot paths), so the performance impact is nil either way — but removing AggressiveInlining would be more consistent with repo conventions.

✅ Correctness — All four serialization paths are consistent

I verified that the separator logic is applied consistently across all code paths:

Path	Writer separator tracking	Reader split logic
Reflection	lastWasText bool, WriteValue(separatorStr)	rawText.Split(separator)
Generated code	lastWasTextVar string variable in emitted code	rawText.Split(charLiteral) emitted
ILGen	lastWasTextLoc LocalBuilder	String.Split(char, StringSplitOptions) IL
Attribute (all paths)	separator ?? ' ' fallback	Split(separator) or Split((char[]?)null)

The ReadContentAsString usage in the ILGen path (vs Reader.ReadString() in generated code) is a pre-existing inconsistency — the original code before this PR already used ReadContentAsString in the ILGen path (the variable was misleadingly named XmlReader_ReadString). This PR correctly renamed it to XmlReader_ReadContentAsString for clarity but did not change the behavior.

✅ Correctness — Mixed-content separator tracking handles nulls correctly

The WriteElements method in ReflectionXmlSerializationWriter.cs correctly handles null items in mixed content:

• When text != null && o is not null: writes text with separator, returns true
• When text != null && o is null: falls through to return emitSeparator (line 313), preserving the separator state without writing anything
• This is verified by the test case "a", null, "b" → "a,b" (no stray separator from null)

✅ Correctness — Default behavior preserved

When Separator is not set ('\0'):

• XmlAttribute: attribute.Separator remains null, falling back to Split((char[]?)null) (whitespace split) and ' ' separator in writers — identical to pre-PR behavior
• XmlText: text.Separator remains null, no split on read, no separator on write — identical to pre-PR behavior (concatenation)

✅ Validation — Correct char validity checks

• ValidateTextSeparatorChar uses XmlCharType.IsTextChar → rejects <, &, ], control chars — correct for text content
• ValidateAttributeSeparatorChar uses XmlCharType.IsAttributeValueChar → additionally rejects ", ', > — correct for attribute values
• The test TypeWithXmlTextSeparatorQuote confirms " is valid as a text separator but invalid as an attribute separator ✅

✅ Test Coverage — Comprehensive

Tests cover: round-trip with comma/space/quote separators, empty strings between separators, single-element arrays, no-separator backward compatibility, invalid separator character rejection, mixed content with elements, null items in mixed content, XmlNode text mapping with separator rejection, and choice-based mixed content.

💡 Suggestion — WriteQuotedCSharpChar could use \u for non-ASCII chars

The WriteQuotedCSharpChar method handles control chars below 32 with \x escapes, but chars between 128-255 could theoretically produce ambiguous \x sequences in generated C# if followed by hex digits. Since validation rejects most problematic chars anyway, this is low risk, but using \u escapes (4-digit, unambiguous) would be more defensive:

<(char)32=> $"\\u{(int)value:X4}",

This is a non-blocking suggestion for robustness.

💡 Observation — Expected.SerializableAssembly.XmlSerializers.cs

The Expected.SerializableAssembly.XmlSerializers.cs file (~5300 lines changed) is a large auto-generated expected-output file that got renumbered because the two new test types shifted all generated method indices by +2. The %%ParentAssemblyId%% placeholder was also restored. This is expected mechanical churn from adding new serializable types.

---

Models contributing: Claude Opus 4.6 (primary), Claude Sonnet 4.5 (sub-agent). GPT-5.3-Codex sub-agent timed out after 10 minutes.

Generated by Code Review for issue #126767 · ◷

[mconnew]

The initial statement:

[XmlAttribute] string[] uses space separation (val1 val2).

Isn't quite right. When reading, it accepts any whitespace character. This includes the typically known tab, form feed, carriage return, new line, and actual space, and any Unicode whitespace. This include unicode codespace of a language which has some more exotic whitespace characters, those are included too. It's conceivable that you want to accept spaces and tabs only, and don't want to allow new lines/carriage returns. Would it be better to have Separator be Separators and a string of characters you want to use for separators?

[mconnew]

The implementation looks good to me based on the intended design. My only feedback is my previous comment, should we be accepting multiple delimiters as the existing functionality already does and this doesn't allow a subset to be used.

[StephenMolloy]

lgtm

[StephenMolloy]

API Proposal for this is #129001

[leculver]

Just one suggestion, but the test file doesn't compile.

[leculver]

Missing a }, so this doesn't compile/run through CI.

[leculver]

I think you also need to escape U+0085/U+2028/U+2029. C# treates these codepoints as newlines:

• U+000D (CR) (handled with \r below)
• U+000A (LF) (handled with \n below)
• U+0085 (NEL)
• U+2028 (LINE SEPARATOR)
• U+2029 (PARAGRAPH SEPARATOR)

[Copilot]

Pull request overview

Copilot reviewed 17 out of 18 changed files in this pull request and generated 2 comments.