NSwag studio code generation unwraps the class properties and puts them in as parameters rather than the object itself.

[patel-jeel92]

WebAPI targets .NET Core 2.1

I have an api call which takes in my custom object as a parameter. When I generate the client code using NSwag Studio, it unwraps all the properties of the custom object and puts those as parameters rather than the object itself. As a result my client looks like this:

System.Threading.Tasks.Task AddNewPerson(string name, int age, sting zodiacSign);

instead of

System.Threading.Tasks.Task AddNewPerson(Person person);

[smariussorin]

Same problem, used [FromBody] to fix de issue.

[Kordonme]

[FromBody] won't work with GET. This is still an issue and should be a setting.

[Caraballo114]

Any update on this? I'm having the same issue as well. I don't want to [FromBody] all my APIs, as it'd make more sense to get the inital issue fixed. I'm guessing this has something to do with the CodeGen.nswag configuration?

[RicoSuter]

Cant this be solved with a custom asp.net core api convention?

[rrr3da]

immo the issue must be solved during json generation step, but I'm not really into openapi specs so maybe this is not standard to achieve.
I would be nice from this controller

[HttpGet]
[ProducesResponseType(typeof(Contact), 200]
public IActionResult Get([FromQuery]ContactQuery query) { ... }

(which produces this output json)...

{
  "v1/contacts": {
    "get": {
      ...
      "parameters" : [
        <each ContactQuery field>
      ]
    }
  }
}

...to have a generated client with the ContactQuery model instead of single split parameters

[packe100]

Hi!
I have the same problem: the complex parameters decorated as "[FromQuery]" are translated with a list of primitive type properties.

Are there news about the resolution of this issue?

[RicoSuter]

The problem is that this cannot be described with openapi/swagger

[packe100]

Hi, thank you for your answer.

That being the case (i.e. no support from openapi), I would say that what I'm trying to do - FromQuery argument automation - is not a common/orthodox practice.
Is there probably a better solution?