ASP.NET MVC and WebAPI methods should not have "Async" suffix

[usarskyy]

Plugin suggests to rename WebAPI actions which is not completely correct. WebAPI action name should not reflect the way how it is executed.

Example: I get a suggestion to rename CityController.Get(...) action to "GetAsync"

[asizikov]

Hi @usarskyy for now as a workaround I can suggest using

[SuppressMessage("ReSharper", "ConsiderUsingAsyncSuffix")]

attribute for the Controller. Another option is // ReSharper disable ConsiderUsingAsyncSuffix comment.

I also have an oposite request #2 and I guess I'll build settings to filter out types for the inspection.

Any exctra information is very appriciated:

• Which APS.NET MVC and WEB API versions are affected?
• Any links to naming guidlines or convensions for WEB API will be good as well.

[asizikov]

And btw which ReSharper version do yo use?

[usarskyy]

Request #2 is similar but in fact related to something else.

In my case I have the following code:

public async Task<ResponseMessage> Register([FromBody] RequestMessage request, CancellationToken cancellationToken) { .... }

This would perfectly fall into suggested MethodNameAsync case if it wasn't a WebAPI action. There is no "must do" naming guideline, you do as you like. For example, my coding guideline is based on a few projects. We (other developers and I) came to a conclusion that if there is no difference for a consumer (i.e., web application) how action is executed (i.e., how to pass arguments and how to handle a result) then there should be no difference in naming convention. In case of code that you call from your C# code, there is a difference. That is why "Async" suffix must be used.

[usarskyy]

We use WebAPI 2, ASP.NET MVC 5 and ReSharper 10 (upgraded yesterday)

[asizikov]

Some links I found about the topic:

MSFT seems to be very inconsistent about naming for async actions:

• http://www.asp.net/mvc/overview/performance/using-asynchronous-methods-in-aspnet-mvc-4
• https://github.com/aspnet/live.asp.net/blob/b881ca904f492e0a807fe60bce4ba5d671bd0b4a/src/live.asp.net/Controllers/AccountController.cs#L24
• https://github.com/shanselman/AspNetPersonaId/blob/8335c24c7ca25a7516d72def7d73d8995d57691a/MVC4/PersonaMVC4Example/Controllers/PersonaController.cs#L23

[usarskyy]

Your examples are newer but in general you have to take into account that old ASP.NET asynchronous actions were written differently than now (https://msdn.microsoft.com/en-us/library/ee728598(v=vs.100).aspx#converting_synchronous_action_methods_to_asynchronous_action_methods). In old times "Async" suffix actually had a concrete meaning and was silently removed by the framework. It can be that some projects are using "Async" suffix to be compatible with old naming convention.

[asizikov]

Yeah, I understand that #2 is different. I mean they are related as they both influence the decision whether or not to show the suggestion. I don't want to hard-code classes or frameworks as I did for test frameworks.
That's why I'm thinking about configurable list of classes/attributes to exclude from analysis.

[Eonasdan]

I'd like to add a +1 to this. MVC action methods do not need the Async suffix.

[posledam]

+1