Thoughts on Async/Await Conversion in a Desktop App - Rick Strahl's Web Log

If you've been following this blog and my Twitter feed, you know I've been going through a lengthy process of updating the Markdown Monster WPF desktop application from using an IE WebBrowser control based editor and preview interface to using the new Chromium Edge WebView2 control. This new control provides a modern browser that use the Chromium engine which provides much better compatibility with modern Web Standards.

The new control has strict requirements to use asynchronous access to make calls into the Web Browser control, which Markdown Monster uses a lot to interact with the editor. The original application wasn't built with Async in mind - especially not when it comes to accessing common operations that you typically don't associate with asynchronous operation like say setting or getting the document text. The process of conversion of Markdown Monster from mostly sync to mostly async has been frustrating as heck and turned out to be a much bigger job than I anticipated. Not only in terms of actual work involved making the conversions, but also with many, many strange side effects that resulted from code going from sync to async despite making use of the async/await infrastructure in .NET.

So in this post I'll go over a few of the issues I ran into, what I tried, what worked and what didn't (hint: lots!). This isn't a comprehensive post about best practices or how to approach async, so if that's what you're expecting or looking for this is not the right place. And frankly I'm not qualified to provide any advice in regards to async processing in desktop applications, as I'm still grappling with properly and efficiently utilizing async in non-server applications where UI interactions are much more susceptible to race conditions than (typically) more linear server applications.

Leave a Comment