TL;DR
I think i found a bug in the c# client code generator that occurs when a string is used with format: uri and causes to use the Uri type but uses new StringContent(string) on request creation.
I was handed an OpenAPI specification that defines endpoints that take plaintext inputs of type string with format uri.
As request body:
requestBody:
content:
text/plain:
schema:
type: string
format: uri
and there's also an endpoint that defines parameters like this:
operation.HasPlainTextBodyParameter is true in this case, as the content type is text/plain. But even if you'd set the content type to something that fits to Uri, such as text/uri-list, the generator will serialize it to json, which is not correct anyway.
If we remove format: uri the code generator will use a string rather than an Uri, so we don't run into the problem. But that would also require me to alter the specification file everytime there's an update.
TL;DR I think i found a bug in the c# client code generator that occurs when a string is used with
format: uri
and causes to use theUri
type but usesnew StringContent(string)
on request creation.I was handed an OpenAPI specification that defines endpoints that take plaintext inputs of type
string
with formaturi
.As request body:
and there's also an endpoint that defines parameters like this:
The C# code generator generates the following client code:
This fails of course, as
body
is neither a string, nor is there a constructor ofStringContent
that takes anUri
.The actual problem is caused by the
Client.Class.liquid
template: https://github.com/RicoSuter/NSwag/blob/b3615b4c4fc23e4b2dc69b8d7d6a420c4931e141/src/NSwag.CodeGeneration.CSharp/Templates/Client.Class.liquid#L215-L216operation.HasPlainTextBodyParameter
istrue
in this case, as the content type istext/plain
. But even if you'd set the content type to something that fits toUri
, such astext/uri-list
, the generator will serialize it to json, which is not correct anyway.If we remove
format: uri
the code generator will use astring
rather than anUri
, so we don't run into the problem. But that would also require me to alter the specification file everytime there's an update.This seems like a bug to me anyway