Async controller actions in Umbraco Part 2

In my previous blog I explained how to get the httpContext to survive an asynchronous callback by using the aspnet:UseTaskFriendlySynchronizationContext application setting and I questioned why this wasn’t set by default. Well I’ve since discovered why that’s the case and it has some pretty significant consequences for Umbraco’s backend CMS. To be clear the Umbraco 6 backend isn’t entirely compatible with the new task friendly synchronisation context, however Umbraco 7 is fully compatible and is actually configured out of the box to use it.

Basically in Umbraco 6, when you set .net to use the task friendly synchronization context you can no longer save changes to doc types and media types. It’s a pain, but not impossible to live with. I’ve resorted to switching off the task friendly context when making doc type changes and switching it back on when I’m done. So why does it error? It’s again due to the changes between the now legacy synchronisation context and the task friendly one.

Within the .net Web Forms framework there is the ability to queue up and execute a number of asynchronous tasks using Page.RegisterAsyncTask() to queue them up and Page.ExecuteRegisteredAsyncTasks() to execute them. When registering tasks you create a new PageAsyncTask object which supports the ability to set a timeout handler, however the task friendly synchronisation context doesn’t support this. If you attempt to set the timeout handler while using the task friendly synchronisation context, you will get an invalid operation error. Which is exactly what Umbraco 6 is doing.

Overall it’s not too hard to work with async tasks in Umbraco 6, but if you have the option you definitely want to be using Umbraco 7. Until the Umbraco devs refactor their ContentTypeControlNew class to remove the timeout handlers, Umbraco 6 just won’t work (completely) with the task friendly synchronisation context.