3 ms·

I agree with the DI for config and async push. Too much ceremony for a very simple task. Async being used by auth can certainly be frustrating if you have sync

by elamje 6y ago

I agree with the DI for config and async push. Too much ceremony for a very simple task. Async being used by auth can certainly be frustrating if you have sync code that needs to use it at some point. Then suddenly you have to redo all sync code that calls the async method. I’ve been experiencing the same issue with some Azure SDKs that only expose async methods rather than both async and sync. Frustrating to have to redo 8 caller functions to make a single sdk call.

mattmanser 6y ago
You can actually just use `.Wait` or `.Result()` most of the time if you just want to make it synchronous if it's just scrappy code. Though you'll probably hit the `async void return` runtime bug at some point where you accidentally return void from a method you tried to make async but then got bored of rewriting everything, so just whack in a .Wait or .Result() but haven't returned Task and the damn thing fails at runtime with a mysterious error making you curse async even more.
- nullsense 6y ago
  >You can actually just use `.Wait` or `.Result()` most of the time if you just want to make it synchronous if it's just scrappy code. You call .GetAwaiter().GetResult(); and avoid mixing sync and async where at all possible.
- ddek 6y ago
  Never, ever, ever do this in production. This will block at least two threads, which will cause premature thread pool starvation at spike loads. This pattern, 'sync-over-async', is to be avoided at all costs, at all times. You're not going to like it, but the MS recommended way of dealing with this is to make your callstack async. In all honest - if you're making an ASP net core web app, go all in on async from the start. If you have to mix and match, never go sync-over-async inside an action.