Nswag: complex type in API [FromBody] signature incorrectly handled in generated TypeScript as string

[adamlubek]

Hi,
I'm using:

• Swashbuckle package (version 5.6.0) in WebApi 2 .NET project to generate json representation of API -
• nswag npm package (version 11.11.3) with swagger2tsclient command to generate TS based on API json representation

nswag swagger2tsclient /Input:swagger.json /Output:src/api.ts /ClassName:{controller}Service /WrapDtoExceptions:true /TypeScriptVersion:2.0 /Template:Angular DateTimeType:Date /GenerateClientClasses:true /GenerateClientInterfaces:true /ImportRequiredTypes:true /BaseUrlTokenName:API_BASE_URL /HttpClass:HttpClient /injectionTokenType:InjectionToken

WebApi controller:

```
public async Task Patch(int id, [FromBody] ComplexType complexType)
{
return this.StatusCode(HttpStatusCode.NoContent);
}

public class ComplexType 
{
    public int Id { get; set; }
    public string Name { get; set; }
}

swagger json for this request params is:

"parameters": [
{
"name": "id",
"in": "path",
"description": "Id",
"required": true,
"type": "integer",
"format": "int32"
},
{
"name": "complexType",
"in": "body",
"description": "ComplexType model",
"required": true,
"schema": { "$ref": "#/definitions/ComplexType" }
}
],
```

the problem is that generated typescript code expects complex type as string which isn't right:

patch(id: number, complexType: string): Observable<any> {

generated code also includes TS class definition for ComplexType but as you can see, string type is used instead of ComplexType in TS function parameter

Am I missing something in my setup? do I need to apply some attribute/command switch to ensure generated typescript is using complex type as parameter instead of string?

[RicoSuter]

Everything looks fine to me... can you provide a complete Swagger spec so I can reproduce this?

[adamlubek]

thanks for quick reply! here it is:

{
  "swagger": "2.0",
  "info": {
    "version": "v1",
    "title": "Api"
  },
  "host": "localhost",
  "basePath": "/Api",
  "schemes": ["http"],
  "paths": {
    "/v1/entities/{id}": {
      "patch": {
        "tags": ["Entites"],
        "summary": "Updates details of the entity for a given entity ID.",
        "operationId": "Entites_Patch",
        "consumes": ["application/xml", "application/json"],
        "produces": ["application/xml", "application/json"],
        "parameters": [
          {
            "name": "id",
            "in": "path",
            "description": "Id of the entity",
            "required": true,
            "type": "integer",
            "format": "int32"
          },
          {
            "name": "updateEntityRequest",
            "in": "body",
            "description": "UpdateEntityRequest model",
            "required": true,
            "schema": { "$ref": "#/definitions/UpdateEntityRequest" }
          }
        ],
        "responses": {
          "200": { "description": "OK", "schema": { "type": "object" } }
        }
      }
    }
  },
  "definitions": {
    "UpdateEntityRequest": {
      "type": "object",
      "properties": {
        "id": { "format": "int32", "type": "integer" },
        "name": { "type": "string" }
      }
    }
  }
}

[RicoSuter]

If I switch the consumes/produces, it works:

    "consumes": [
      "application/json",
      "application/xml"
    ],
    "produces": [
      "application/json",
      "application/xml"
    ],

have to check whether we have to fix this in the generator or if this is expected (probably not :-))

[adamlubek]

switching to have application/json first indeed solved it, thanks @RSuter :)

[RicoSuter]

Yep, but it's just a temporary patch until this is fixed...

[RicoSuter]

Release v11.17.6