Je travaille sur un service Web utilisant la nouvelle WebAPI d'ASP.NET MVC qui servira des fichiers binaires, principalement .cabet des .exefichiers.

La méthode de contrôleur suivante semble fonctionner, ce qui signifie qu'elle renvoie un fichier, mais elle définit le type de contenu sur application/json:

public HttpResponseMessage<Stream> Post(string version, string environment, string filetype)
{
    var path = @"C:\Temp\test.exe";
    var stream = new FileStream(path, FileMode.Open);
    return new HttpResponseMessage<Stream>(stream, new MediaTypeHeaderValue("application/octet-stream"));
}

Y a-t-il une meilleure manière de faire cela?

Essayez d'utiliser un simple HttpResponseMessageavec sa Contentpropriété définie sur a StreamContent:

// using System.IO;
// using System.Net.Http;
// using System.Net.Http.Headers;

public HttpResponseMessage Post(string version, string environment,
    string filetype)
{
    var path = @"C:\Temp\test.exe";
    HttpResponseMessage result = new HttpResponseMessage(HttpStatusCode.OK);
    var stream = new FileStream(path, FileMode.Open, FileAccess.Read);
    result.Content = new StreamContent(stream);
    result.Content.Headers.ContentType = 
        new MediaTypeHeaderValue("application/octet-stream");
    return result;
}

Quelques points à noter sur l' streamutilisation:

• Vous ne devez pas appeler stream.Dispose(), car l'API Web doit toujours pouvoir y accéder lorsqu'elle traite les méthodes du contrôleur resultpour renvoyer des données au client. Par conséquent, n'utilisez pas de using (var stream = …)bloc. L'API Web disposera du flux pour vous.

• Assurez-vous que la position actuelle du flux est définie sur 0 (c'est-à-dire le début des données du flux). Dans l'exemple ci-dessus, c'est une donnée puisque vous venez d'ouvrir le fichier. Cependant, dans d'autres scénarios (comme lorsque vous écrivez pour la première fois des données binaires dans a MemoryStream), assurez-vous de stream.Seek(0, SeekOrigin.Begin);ou définissezstream.Position = 0;

• Avec les flux de fichiers, la spécification explicite des FileAccess.Readautorisations peut aider à éviter les problèmes de droits d'accès sur les serveurs Web; Les comptes de pool d'applications IIS reçoivent souvent uniquement des droits d'accès en lecture / liste / exécution sur wwwroot.

Pour Web API 2 , vous pouvez implémenter IHttpActionResult. Voici la mienne:

using System;
using System.IO;
using System.Net;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Threading;
using System.Threading.Tasks;
using System.Web;
using System.Web.Http;

class FileResult : IHttpActionResult
{
    private readonly string _filePath;
    private readonly string _contentType;

    public FileResult(string filePath, string contentType = null)
    {
        if (filePath == null) throw new ArgumentNullException("filePath");

        _filePath = filePath;
        _contentType = contentType;
    }

    public Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken)
    {
        var response = new HttpResponseMessage(HttpStatusCode.OK)
        {
            Content = new StreamContent(File.OpenRead(_filePath))
        };

        var contentType = _contentType ?? MimeMapping.GetMimeMapping(Path.GetExtension(_filePath));
        response.Content.Headers.ContentType = new MediaTypeHeaderValue(contentType);

        return Task.FromResult(response);
    }
}

Ensuite, quelque chose comme ça dans votre contrôleur:

[Route("Images/{*imagePath}")]
public IHttpActionResult GetImage(string imagePath)
{
    var serverPath = Path.Combine(_rootPath, imagePath);
    var fileInfo = new FileInfo(serverPath);

    return !fileInfo.Exists
        ? (IHttpActionResult) NotFound()
        : new FileResult(fileInfo.FullName);
}

Et voici une façon de dire à IIS d'ignorer les demandes avec une extension afin que la demande parvienne au contrôleur:

<!-- web.config -->
<system.webServer>
  <modules runAllManagedModulesForAllRequests="true"/>

Pour ceux qui utilisent .NET Core:

Vous pouvez utiliser l'interface IActionResult dans une méthode de contrôleur API, comme ceci ...

    [HttpGet("GetReportData/{year}")]
    public async Task<IActionResult> GetReportData(int year)
    {
        // Render Excel document in memory and return as Byte[]
        Byte[] file = await this._reportDao.RenderReportAsExcel(year);

        return File(file, "application/vnd.openxmlformats", "fileName.xlsx");
    }

Cet exemple est simplifié, mais devrait faire passer le message. Dans .NET Core, ce processus est tellement plus simple que dans les versions précédentes de .NET - c'est-à-dire sans définir le type de réponse, le contenu, les en-têtes, etc.

En outre, bien sûr, le type MIME pour le fichier et l'extension dépendra des besoins individuels.

Référence: SO Post Answer by @NKosi

Bien que la solution suggérée fonctionne correctement, il existe un autre moyen de renvoyer un tableau d'octets à partir du contrôleur, avec un flux de réponse correctement formaté:

• Dans la demande, définissez l'en-tête "Accept: application / octet-stream".
• Côté serveur, ajoutez un formateur de type de support pour prendre en charge ce type MIME.

Malheureusement, WebApi n'inclut aucun formateur pour "application / octet-stream". Il y a une implémentation ici sur GitHub: BinaryMediaTypeFormatter (il y a des adaptations mineures pour le faire fonctionner pour webapi 2, les signatures de méthode ont changé).

Vous pouvez ajouter ce formateur dans votre configuration globale:

HttpConfiguration config;
// ...
config.Formatters.Add(new BinaryMediaTypeFormatter(false));

WebApi doit maintenant utiliser BinaryMediaTypeFormattersi la demande spécifie l'en-tête Accept correct.

Je préfère cette solution car un contrôleur d'action renvoyant l'octet [] est plus confortable à tester. Cependant, l'autre solution vous permet plus de contrôle si vous souhaitez renvoyer un autre type de contenu que "application / octet-stream" (par exemple "image / gif").

Pour toute personne ayant le problème de l'API appelée plus d'une fois lors du téléchargement d'un fichier assez volumineux en utilisant la méthode dans la réponse acceptée, veuillez définir la mise en mémoire tampon des réponses sur true System.Web.HttpContext.Current.Response.Buffer = true;

Cela garantit que tout le contenu binaire est mis en mémoire tampon côté serveur avant d'être envoyé au client. Sinon, vous verrez plusieurs demandes envoyées au contrôleur et si vous ne les gérez pas correctement, le fichier sera corrompu.

La surcharge que vous utilisez définit l'énumération des formateurs de sérialisation. Vous devez spécifier explicitement le type de contenu comme:

httpResponseMessage.Content.Headers.ContentType = new MediaTypeHeaderValue("application/octet-stream");

Tu pourrais essayer

httpResponseMessage.Content.Headers.Add("Content-Type", "application/octet-stream");