Каковы риски обертывания Async/Await IAsyncOperations кодом Task.Wait()?

В настоящее время я пытаюсь перенести значительное количество существующего синхронного кода на WinRT.

Как часть этого, я сталкиваюсь с проблемами в существующем коде, ожидая, что некоторые операции будут синхронными, например.для файлового ввода-вывода

Чтобы адаптировать этот существующий код для работы с API-интерфейсом стиля IAsyncOperation в WinRT, я использовал метод обертывания IAsyncOperation с помощью метода расширения, например:

namespace Cirrious.MvvmCross.Plugins.File.WinRT
{
    public static class WinRTExtensionMethods
    {
        public static TResult Await(this IAsyncOperation operation)
        {
            var task = operation.AsTask();
            task.Wait();
            if (task.Exception != null)
            {
                // TODO - is this correct?
                throw task.Exception.InnerException;
            }

            return task.Result;
        }
    }
}

из MvvmCross WinRT ExtensionMethods- с аналогичным методом для IAsyncAction

Эти оболочки, кажется, работают - и они позволяют мне использовать методы Asyncв синхронном коде, например:

    public IEnumerable GetFilesIn(string folderPath)
    {
        var folder = StorageFolder.GetFolderFromPathAsync(ToFullPath(folderPath)).Await();
        var files = folder.GetFilesAsync().Await();
        return files.Select(x => x.Name);
    }

Я понимаю, что это не так. т действительно в духе WinRT; но я ожидаю, что эти методы обычно вызываются только в фоновых потоках; и я пишу это с целью сделать мой код кросс-платформенным, в том числе с платформами, которые еще не поддерживают await-async, и/или с разработчиками, которые еще не готовы совершить прыжок.

Итак... вопрос: какие риски я получаю, используя этот тип кода?

И второй вопрос: есть ли лучший способ повторного использования кода для таких областей, как файловый ввод-вывод?