Mvc.Api.Analyzers not recognizing methods from a Base Class

[prmces]

My app use a Base Controller to reuse some methods inside my Api controllers.

The MVC.API.Analyzer library is looking at my controllers that inherit from this base controller, trying to found undocumented reponse codes. That is correct.

But, inside my Base Controller, I have undocument methods. The swagger UI shows me correctly all the inherited methods, but the analyzers could not point me that I am missing something.

The Controller that inherits from BaseController and its swagger doc. Correct.

The Base Controller. Wrong. (Im missing documentation for NotFound and BadRequest)

Any help on that??

[mkArtakMSFT]

Thanks for contacting us, @prmces.
@pranavkm, please look into this when you'll be back. Thanks!

[pranavkm]

The analyzer uses the same behavior as runtime to determine if something's a controller. For instance, generic types or abstract types aren't considered controllers. While this is true at runtime, it clearly doesn't work very well for inherited types like yours. We should consider relaxing this restriction.

[topres]

Just to add a note to this @mkArtakMSFT

The same issue occurs when using local functions or Func in the controller action. Would be nice if the analyzer check was recursive in the controller action path.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.