Per the .NET SDK parameter ordering guideline, the prescribed order is:
- Required Path
- Required Query/Header
- Body
- ContentType
- Optional Query/Header
- Request Context
For multipart operations, the generator correctly produces (path, body, contentType, options). But for non-multipart operations with a @header contentType union, it produces (path, contentType, body, options) — placing contentType before body.
Example:
op UpdateSkillDefaultVersion(
@path skill_id: string,
@header contentType: "application/json" | "application/x-www-form-urlencoded",
@body body: SetDefaultSkillVersionBody,
): SkillResource;
Generated (current — incorrect):
UpdateSkillDefaultVersion(string skillId, string contentType, BinaryContent content, RequestOptions options = null)
Expected (per guideline):
UpdateSkillDefaultVersion(string skillId, BinaryContent content, string contentType, RequestOptions options = null)
The multipart variant already generates the correct order: (skillId, content, contentType, options). The fix should apply the same body-before-contentType ordering to non-multipart operations as well.
For your reference, here's the generated operation for non multipart operation.
Per the .NET SDK parameter ordering guideline, the prescribed order is:
For multipart operations, the generator correctly produces
(path, body, contentType, options). But for non-multipart operations with a@header contentTypeunion, it produces(path, contentType, body, options)— placing contentType before body.Example:
Generated (current — incorrect):
Expected (per guideline):
The multipart variant already generates the correct order:
(skillId, content, contentType, options). The fix should apply the same body-before-contentType ordering to non-multipart operations as well.For your reference, here's the generated operation for non multipart operation.