Return to Answer

The way to handle this pattern is to ensure that all I/O is asynchronous. Synchronous I/O methods cause the current thread to block while it waits for a response from the I/O destination (network, file-system, etc).

Another thing to consider is that await should be used when you need a return value or when you need the awaited code to finish before doing something else. If you don't need either of those things, you can "fire and forget" your async method with Task.Run.

So, for the most efficient use of computing resources, if RemoveRoles does any I/O, it should become await RemoveRolesAsync and the I/O methods called by RemoveRolesAsync should also be async (and possibly awaited).

If performance is not your utmost concern, then it's fine to do some synchronous I/O on an async thread. It is a technical debt though. (In this case, you might want to call the first async method with ConfigureAwait, depending on where the code is running.)

Here's a more in-depth look at the best practices - https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

Here are some notes about the behavior of ConfigureAwait in different environments like ASP.NET, WebAPI, etc - http://stackoverflow.com/questions/13489065/best-practice-to-call-configureawait-for-all-server-side-code

The way to handle this pattern is to ensure that all I/O is asynchronous. Synchronous I/O methods cause the current thread to block while it waits for a response from the I/O destination (network, file-system, etc).

Another thing to consider is that await should be used when you need a return value or when you need the awaited code to finish before doing something else. If you don't need either of those things, you can "fire and forget" your async method with Task.Run.

So, for the most efficient use of computing resources, if RemoveRoles does any I/O, it should become await RemoveRolesAsync and the I/O methods called by RemoveRolesAsync should also be async (and possibly awaited).

If performance is not your utmost concern, then it's fine to do some synchronous I/O on an async thread. It is a technical debt though. (In this case, you might want to call the first async method with ConfigureAwait, depending on where the code is running.)

Here's a more in-depth look at the best practices - https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

Here are some notes about the behavior of ConfigureAwait in different environments like ASP.NET, WebAPI, etc - https://stackoverflow.com/questions/13489065/best-practice-to-call-configureawait-for-all-server-side-code

The way to handle this pattern is to ensure that all I/O is asynchronous. Synchronous I/O methods cause the current thread to block while it waits for a response from the I/O destination (network, file-system, etc).

Another thing to consider is that await should be used when you need a return value or when you need the awaited code to finish before doing something else. If you don't need either of those things, you can "fire and forget" your async method with Task.Run.

So, for the most efficient use of computing resources, if RemoveRoles does any I/O, it should become await RemoveRolesAsync and the I/O methods called by RemoveRolesAsync should also be async (and possibly awaited).

If performance is not your utmost concern, then it's fine to do some synchronous I/O on an async thread. It is a technical debt though. (In this case, the first async method should be called with ConfigureAwait if possible (as explained in the best practices article below.))

Here's a more in-depth look at the best practices - https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

The way to handle this pattern is to ensure that all I/O is asynchronous. Synchronous I/O methods cause the current thread to block while it waits for a response from the I/O destination (network, file-system, etc).

Another thing to consider is that await should be used when you need a return value or when you need the awaited code to finish before doing something else. If you don't need either of those things, you can "fire and forget" your async method with Task.Run.

So, for the most efficient use of computing resources, if RemoveRoles does any I/O, it should become await RemoveRolesAsync and the I/O methods called by RemoveRolesAsync should also be async (and possibly awaited).

If performance is not your utmost concern, then it's fine to do some synchronous I/O on an async thread. It is a technical debt though. (In this case, you might want to call the first async method with ConfigureAwait, depending on where the code is running.)

Here's a more in-depth look at the best practices - https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

Here are some notes about the behavior of ConfigureAwait in different environments like ASP.NET, WebAPI, etc - http://stackoverflow.com/questions/13489065/best-practice-to-call-configureawait-for-all-server-side-code

The way to handle this pattern is to ensure that all I/O is asynchronous. Synchronous I/O methods cause the current thread to block while it waits for a response from the I/O destination (network, file-system, etc).

Another thing to consider is that await should be used when you need a return value or when you need the awaited code to finish before doing something else. If you don't need either of those things, you can "fire and forget" your async method with Task.Run.

So, for the most efficient use of computing resources, if RemoveRoles does any I/O, it should become await RemoveRolesAsync and the I/O methods called by RemoveRolesAsync should also be async (and possibly awaited).

If performance is not your utmost concern, then it's fine to do some synchronous I/O on an async thread. It is a technical debt though.

Here's a more in-depth look at the best practices - https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

The way to handle this pattern is to ensure that all I/O is asynchronous. Synchronous I/O methods cause the current thread to block while it waits for a response from the I/O destination (network, file-system, etc).

Another thing to consider is that await should be used when you need a return value or when you need the awaited code to finish before doing something else. If you don't need either of those things, you can "fire and forget" your async method with Task.Run.

So, for the most efficient use of computing resources, if RemoveRoles does any I/O, it should become await RemoveRolesAsync and the I/O methods called by RemoveRolesAsync should also be async (and possibly awaited).

If performance is not your utmost concern, then it's fine to do some synchronous I/O on an async thread. It is a technical debt though. (In this case, the first async method should be called with ConfigureAwait if possible (as explained in the best practices article below.))

Here's a more in-depth look at the best practices - https://msdn.microsoft.com/en-us/magazine/jj991977.aspx