Возврат файла, загруженного в async во встроенном ПО (асинхронность и удаление потоков) - PullRequest
Новая
       13

Возврат файла, загруженного в async во встроенном ПО (асинхронность и удаление потоков)

0 голосов
/ 02 февраля 2019

Хотя этот конкретный вопрос касается встроенного и FileReponseAsync, но он, вероятно, больше связан с обработкой потоков и асинхронностью в Задачах на C #.

Я использую EmbeddedIO (мне нужен быстрый и грязный веб-сервери до сих пор это работало как чудо - однако отсутствие документации немного расстраивает), но я пытаюсь вернуть файл со следующим кодом: 

  var file = new FileInfo(Path.Combine(FileLocations.TemplatePath, templateFile.FilePath));
  string fileExtension = Path.GetExtension(templateFile.FilePath);

  return this.FileResponseAsync(file, MimeTypes.DefaultMimeTypes.Value.ContainsKey(fileExtension) ? 
    MimeTypes.DefaultMimeTypes.Value[fileExtension] : "application/octet-stream");

Я получаю следующую ошибку:

Сообщение
Имя неверного модуля: Модуль веб-API
Невозможно получить доступ к закрытому файлу.
Трассировка стека
в System.IO .__ Error.FileNotOpen ()

Это имеет смысл, поскольку в коде EmbedIO FileResponseAsync выглядит следующим образом: 

using (FileStream fileStream = file.OpenRead())
    return context.BinaryResponseAsync(fileStream, ct, useGzip);

и поток файлов будет удален, как только BinaryReponse вернется.Я решил проблему, изменив свой код так, чтобы он не избавлялся от файлового потока: 

var fileStream = file.OpenRead();
return this.BinaryResponseAsync(fileStream);

Хотя это работает, кажется неправильным полагаться на сборщик мусора для удаления этих файлов на более позднем этапе.Как должны обрабатываться такие ресурсы (не только в EmbeddedIO, но и в современном асинхронном мире)?

...