Nullability is not respected for form parameters

[dccs-pwurzinger]

Observed in: Swashbuckle.AspNetCore 6.4.0

Nullability of (primitive) form parameters is not respected (i.e. misses nullable: true) in the generated schema.

Can reproduce that by using a Controller in ASP.NET Core (6 or 7, doesn't matter), saying

[HttpPost]
public void Test([FromForm] int? nullableInteger, IFormFile file) { }

resulting in

"requestBody": {
  "content": {
    "multipart/form-data": {
      "schema": {
        "type": "object",
        "properties": {
          "nullableInteger": {
            "type": "integer",
            "format": "int32"
          },
          "file": {
            "type": "string",
            "format": "binary"
          }
        }
      }
...

I debugged into the Swashbuckle code to see what's going on, and it seems that for form parameters there is no associated DataProperty, essentially leading to not rendering some metadata properties at all:

isRequired
isNullable
isReadOnly
isWriteOnly

Can't tell if isReadOnly or isWriteOnly would make sense for form parameters, but isRequired and isNullable definitely do. Our use case is a generated C# client (via NSwag), that therefore has a mismatching nullability.

Our workaround currently is an additional IRequestBodyFilter, that sets the nullability of the affected properties manually.

[wolszakp]

Bumping this up - I observed the same behaviour for query parameters

[Havunen]

This should be supported in DotSwashbuckle but you need to enable Nullable in csproj and then set option: c.SupportNonNullableReferenceTypes to true

[martincostello]

To make issue tracking a bit less overwhelming for the new maintainers (see #2778), I've created a new tracking issue to roll-up various nullability issues here: #2793.

We'll refer back to this issue from there and include it as part of resolving that issue, but I'm going to close this one to help prune the backlog.