Swashbuckle.aspnetcore: [SwaggerResponse] type or namespace not found

[Hossrod]

I'm following the tutorial at: https://docs.asp.net/en/latest/tutorials/web-api-help-pages-using-swagger.html

"Swashbuckle": "6.0.0-beta902"

Everything is working fine up to the part about decorating responses by using [SwaggerResponse]. Visual Studio reports that SwaggerResponse type or namespace cannot be found and I can't compile because of this. If I right click it, VS suggested fixes are only things like generating a new class (as opposed to suggesting some missing using statement).

Don't know if this is a bug/regression, or if I'm missing something.

Thanks!

[domaindrivendev]

Yep this is breaking change between beta901 and beta902. I do expect there might be more breaking changes to come and this why I only have beta versions available. But, it's getting close to a stable version.

I've submitted a PR to get the docs updated. Check it out to see the changes you need to make. NOTE: If you're not using your own custom "index.html", you can ignore the changes to that file.

https://github.com/aspnet/Docs/pull/1794/files

[Hossrod]

Thanks that worked!

One thing I miss with [SwaggerResponse] is being able to define my own string all in one line/place. To do so now, it looks like I need to use both XML comments and [ProducesResponseType], which is a little easier to make mistakes.

Example

/// <response code="201">Item created successfully.</response>
[ProducesResponseType(typeof(Item), 201)]

Rather than

[SwaggerResponse(201, "Item created successfully.", typeof(Item))]

[domaindrivendev]

Yep I did consider that and concluded its an acceptable trade off. On the flip side

1. Your API dll doesn't need to depend on SB.
2. Theres consistency - now all free text is typically provided via comments and everything else via code
3. Multiline comments get pretty ugly in attributes
4. The built-in metadata is enriched and consistent in case anything else (other than SB) wanted to use it

[Hossrod]

Those are indeed acceptable trade-offs. Thanks for your work on this!

[Slacquer]

It is a nice trade off, however it still find myself having to circumvent most of this by using filtering simply to be able to have a BASE generic controller, thus not having to have typeof(item) (doesnt work on generics). I love this product, but this typeof requirement is killing me.