Hey,
I'm using NSwagStudio x64 v11.19.2.0
With below ASP web api 2 controller:
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
[HttpPut, Route("{id}/expiry")]
[SwaggerResponse(200, typeof(bool))]
public async Task<IHttpActionResult> PutExpiry([FromUri] string id, [FromBody] TimeSpan? expiry)
{
await Task.Yield();
var success = true;
return Ok(success);
}
}
public class ValueDto
{
[Required]
public string Id { get; set; }
}
In NSwag Studio I get different C# client when selecting Swagger2 vs OpenApi3.
Swagger2:
public System.Threading.Tasks.Task<bool> PutExpiryAsync(string id, System.TimeSpan? expiry)
OpenApi3:
public System.Threading.Tasks.Task<bool> PutExpiryAsync(string id, System.TimeSpan expiry)
Notice in OpenApi3 the System.TimeSpan is not nullable.
For now I manually change the generated code to 'TimeSpan?', but fear another dev might overwrite it in future when they re-generate client.
The next version (on master) should improve Open API 3 a lot and fix that... will check that with the latest version.
The spec is generated with NSwag?
The spec was generated with NSwagStudio in the outputs pane (so i think so).
I specified the path to the ASP Web api 2 assembly file in input pane, then click generate outputs: which generates the Specification and C# client.
When is the next release (from master) for NSwagStudio expected, and will i be able to download it from http://rsuter.com/Projects/NSwagStudio/installer.php ?
You can download it here: https://ci.appveyor.com/project/rsuter/nswag-25x6o/build/artifacts
But you have to first uninstall the current version (because the latest version has the same version as the released one which might lead to problems). Just check that the used NJsonSchema version is v9.11.0 (can be found on top of the spec/clients).
Unfortunately the issue still persists in https://ci.appveyor.com/api/buildjobs/v9mlpx87hjtsb1ah/artifacts/src%2FNSwagStudio.Installer%2Fbin%2FRelease%2FNSwagStudio.msi
I still see the TimeSpan parameter generated for OpenApi3 in the above msi.
Looks good to me:

(but with the api explorer version)
Can you post the generated spec?
Below is the OpenApi3 json spec by NswagStudio:
{
"x-generator": "NSwag v11.19.2.0 (NJsonSchema v9.11.0.0 (Newtonsoft.Json v9.0.0.0))",
"openapi": "3.0.0",
"info": {
"title": "My Title",
"version": "1.0.0"
},
"consumes": [
"application/json"
],
"produces": [
"application/json"
],
"paths": {
"/api/values/{id}/expiry": {
"put": {
"tags": [
"Values"
],
"operationId": "Values_PutExpiry",
"parameters": [
{
"name": "id",
"in": "path",
"required": true,
"schema": {
"type": "string",
"nullable": true
},
"x-position": 1
}
],
"requestBody": {
"x-name": "expiry",
"content": {
"application/json": {
"schema": {
"type": "string",
"format": "time-span"
}
}
},
"required": true,
"x-position": 2
},
"responses": {
"200": {
"description": "",
"content": {
"application/json": {
"schema": {
"type": "boolean"
}
}
}
}
}
}
}
},
"components": {}
}
Ah, it's a body parameter, this is the problem:

After some research I got to this conclusion:
Important for client generators:
ASP.NET Core
Web API
I've added AllowNullableBodyParameters setting (default: true) - now nullable should be correctly handled in OpenAPI 3 (without changing anything). In the next major release (v12) the default will be set to false to reflect the current implementation of ASP.NET Core 2+... Keeping default true to not break anyone now.
… but eventually, we should load the nullable information from API Explorer.
Thanks I appreciate the swift fix.
Is there a NSwagStudio msi I should try to verify this fix ?
I think same link theres a new option in the ui
👍 that worked https://ci.appveyor.com/api/buildjobs/v9mlpx87hjtsb1ah/artifacts/src%2FNSwagStudio.Installer%2Fbin%2FRelease%2FNSwagStudio.msi
Cheers and Thanks!!
v11.20.0 is released, please retest - hope my last commit didnt break it - but it's asp.net core 2+ only...
Just verified :-) works on x64 11.20.0.0.
Most helpful comment
I've added AllowNullableBodyParameters setting (default: true) - now nullable should be correctly handled in OpenAPI 3 (without changing anything). In the next major release (v12) the default will be set to false to reflect the current implementation of ASP.NET Core 2+... Keeping default true to not break anyone now.