Make the "Async" suffix optional globally not just for test methods

[girtsl]

This extension offers a neat refactoring - to convert a method to async - and this is the reason I found it after getting tired of changing the method signatures manually and started to look for an automated solution. However, this refactoring also does other things, without the possibility to turn them off:

• it automatically adds the suffix "Async";
• changes all inner calls to their async counterparts, if such exist.

I'm aware that the "Async" suffix is a MS convention:

You should add "Async" as the suffix of every async method name you write.

This is the convention used in .NET to more easily differentiate synchronous and asynchronous methods. Certain methods that aren't explicitly called by your code (such as event handlers or web controller methods) don't necessarily apply. Because they are not explicitly called by your code, being explicit about their naming isn't as important.

This might have been more relevant back when those guidelines were first written, but as some, me included, have come to think, only adds noise to the code. Take this comment - #31 (comment) - for an example, or the excellent write-up by Particular Software - https://docs.particular.net/nservicebus/upgrades/5to6/async-suffix.

I thought this extension would save me time but now I need to manually rename methods back by removing the "Async" suffix, making it a deal-breaker.
For the other refactoring - changing all inner calls to their async counterparts - I have not yet encountered a case where it has lead to an unwelcome result, but only because I've not used it on code that has such async counterparts. Still, it would be nice to be able to turn it off.

Thank you for considering this proposal.

[dmcbride]

Honestly, all of the options here should be individually configurable to be test-only or universal:

ConfigureAwait
Async suffix
Eliding await

Obviously, turning these all off universally means that maybe this isn't the extension for you, and that's fine. But there are some aspects here which would really help, and others that are difficult to integrate into our codebase, so it would be really helpful if those that are difficult could be turned off, and we can see the positives easier.