Асинхронная и синхронная версии метода

Вы не должны писать асинхронные оболочки для синхронных методов , но вы также не должны писать синхронные оболочки для асинхронных методов - это и антипаттерны.

Подсказка: «естественно асинхронный» в основном означает на основе ввода / вывода, за некоторыми исключениями. Одним из таких исключений, к сожалению, являются некоторые операции с файловой системой, в том числе перемещение файлов, которые должны быть асинхронными, но API не поддерживают асинхронность, поэтому мы должны притворяться, что она синхронная.

В вашем случае DownloadToCache определенно является асинхронным. В этих случаях я предпочитаю выставлять только асинхронный API .

Если вы должны (или действительно хотите ) также поддерживать синхронный API, я рекомендую взломать логический аргумент . Семантика заключается в том, что если вы передадите sync:true, то возвращаемое задание уже выполнено. Это позволяет вам сохранять логику в одном методе и писать очень маленькие оболочки без ошибок, обычно связанных с этими оболочками:

private static async Task DownloadToCacheAsync(bool sync)
{
  ...do some analysis to get download locations...
  using (var wc = new WebClient())
  {
    if (sync)
      wc.DownloadFile(new Uri(content.Url), targetPath);
    else
      await wc.DownloadFileTaskAsync(new Uri(content.Url), targetPath);
  }
  ...do other stuff...
}
public static Task DownloadToCacheAsync() => DownloadToTaskAsync(sync: false);
public static void DownloadToCache() => DownloadToTaskAsync(sync: true).GetAwaiter().GetResult();