Propagate tcgc SerializationOptions for body parameters and responses

[Copilot]

tcgc 0.68.0 added serializationOptions to SdkBodyParameter and SdkHttpResponse, but the C# emitter and MTG were still inferring wire format from the content-type header. This PR plumbs that data through so MTG can consume it directly, and switches the first XML wire-format detection site to use the new metadata.

Emitter (TypeScript)

• Added serializationOptions: SerializationOptions (required) to InputBodyParameter and OperationResponse, matching the existing shape on InputModelType / InputModelProperty.
• Populated the field in fromBodyParameter and fromSdkHttpOperationResponse by copying straight from tcgc.

MTG (Microsoft.TypeSpec.Generator.Input)

• Added nullable SerializationOptions (of type InputSerializationOptions) to InputBodyParameter and InputOperationResponse, with constructor parameters defaulted to null for back-compat.
• Updated InputBodyParameterConverter and InputOperationResponseConverter to read the new serializationOptions JSON field.
• Added a new InputBinarySerializationOptions type (IsFile, IsText, ContentTypes, Filename) and InputBinarySerializationOptionsConverter, plumbed through InputSerializationOptions / InputSerializationOptionsConverter so that binary payload metadata emitted by tcgc on model types can be deserialized in MTG. Filename is typed as InputModelProperty?, matching InputMultipartOptions.Filename.

MTG (Microsoft.TypeSpec.Generator.ClientModel)

• ScmMethodProviderCollection.TryGetXmlCollectionNamesForResponse now gates on response.SerializationOptions?.Xml instead of scanning response.ContentTypes for application/xml, consuming the propagated metadata directly.
• Extended the test-only InputFactory.OperationResponse helper with an optional serializationOptions parameter and updated the affected XML list response test to supply it.

Tests

• Emitter unit tests in model-type.test.ts covering body parameter serializationOptions propagation:
  • application/json + string body — asserts bodyParam.serializationOptions.json is populated.
  • Http.File (application/octet-stream) body — asserts the body's model type carries serializationOptions.binary with the full set of properties: isFile === true, isText === false, contentTypes === ["application/octet-stream"], and filename.name === "filename". Also asserts that the body parameter's own serializationOptions has neither json nor xml set (tcgc only derives json/xml for body params from content types; binary lives on the model type).
• Added serialization-options deserialization tests directly inside TypeSpecInputConverterTests in Microsoft.TypeSpec.Generator.Input.Tests validating JSON deserialization of InputSerializationOptions (empty, json, xml, binary with all properties including filename, binary defaults, unknown property tolerance), InputBodyParameter.SerializationOptions (json, binary with filename, absent → null), and InputOperationResponse.SerializationOptions (xml, binary with filename, absent → null).

Follow-up

One header/content-type-based wire-format site remains for a separate change: MrwSerializationTypeDefinition.Xml.cs reads the Content-Type response header at runtime to branch between application/json and application/xml; converting that to consume SerializationOptions is the natural next step.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@typespec/http-client-csharp@10730

commit: 95973fa

[jorgerangel-msft]

@copilot lets add unit tests in the generator to validate the serialization options are properly parsed

[Copilot]

@copilot lets add unit tests in the generator to validate the serialization options are properly parsed

Added InputSerializationOptionsTests in a762fa7 with 11 unit tests covering:

• Empty InputSerializationOptions round-trip
• JSON / XML / Binary options parsing on InputSerializationOptions
• Binary defaults (only isFile)
• InputBodyParameter.SerializationOptions parsing (with json), with binary, and with the field absent (defaults to null)
• InputOperationResponse.SerializationOptions parsing (with xml), and absent (defaults to null)
• Unknown property in serializationOptions is ignored

All 125 Microsoft.TypeSpec.Generator.Input.Tests pass.

[Copilot]

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• cdn.jsdelivr.net
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node /home/REDACTED/work/_temp/ghcca-node/node/bin/node --enable-source-maps /home/REDACTED/work/_temp/copilot-developer-action-main/dist/index.js (dns block)
• unpkg.com
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node /home/REDACTED/work/_temp/ghcca-node/node/bin/node --enable-source-maps /home/REDACTED/work/_temp/copilot-developer-action-main/dist/index.js (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[jorgerangel-msft]

@copilot there are test failing in CI. We need to ensure we regenerate all the test libraries and then ensure all tests are passing

[Copilot]

@copilot there are test failing in CI. We need to ensure we regenerate all the test libraries and then ensure all tests are passing

Regenerated all 74 test tspCodeModel.json fixtures via ./eng/scripts/Generate.ps1 in 95973fa — they now include the new serializationOptions field on body parameters and responses. All generator unit test suites pass locally: Microsoft.TypeSpec.Generator.Input.Tests (126), Microsoft.TypeSpec.Generator.ClientModel.Tests (1334), Microsoft.TypeSpec.Generator.Tests (1490).