In my ASP.NET 5 app, I want to load some data from Azure into a cache inside my Startup.Configure method. The Azure SDK exposes async methods exclusively. Typically, calling an
The example code in the blog you linked to was only using sync-over-async to populate a database with example data; that call wouldn't exist in a production app.
First, I'd say that if you truly need Configure
to be asynchronous, then you should raise an issue with the ASP.NET team so it's on their radar. It would not be too difficult for them to add support for a ConfigureAsync
at this point (that is, before release).
Second, you've got a couple of approaches to the problem. You could use task.Wait
(or better yet, task.GetAwaiter().GetResult()
, which avoids the AggregateException
wrapper if an error does occur). Or, you could cache the task rather than the result of the task (which works if IMemoryCache
is more of a dictionary than some weird serialize-into-binary-array-in-memory thing - I'm looking at you, previous versions of ASP.NET).
If this is considered an acceptable practice, what - if any - error handling do I need?
Using GetAwaiter().GetResult()
would cause the exception (if any) to propagate out of Configure
. I'm not sure how ASP.NET would respond would be if configuring the application failed, though.
I haven't provided any mechanism to cancel the async operation.
I'm not sure how you can "cancel" the setup of an application, so I wouldn't worry about that part of it.