333 messaggi dal 05 novembre 2012
Nel metodo del controller

è una banalità ma puoi utilizzare direttamente lo stream nel return

File(ms, "application/zip", "export.csv.zip");


Conviene implementare il buffer anche qua, giusto?


Penso di si...in ogni caso attendi il parare di Moreno

Utilizza anche qui (per gli oggetti IDisposable) l'istruzione using...leggi qui per approfondire l'utilizzo dell'istruzione using

/Ciao

Alessio
144 messaggi dal 26 febbraio 2007
non so perchè ma se faccio ms (anzichè .ToArray()) mi da errore perchè i byte non tornano.

Mentre nelle funzioni non sto utilizzando le using altrimenti nella response gli stream sono chiusi e falliscono.
333 messaggi dal 05 novembre 2012
Federico.C ha scritto:
non so perchè ma se faccio ms (anzichè .ToArray()) mi da errore perchè i byte non tornano.

ms.Position = 0; prima del return

Mentre nelle funzioni non sto utilizzando le using altrimenti nella response gli stream sono chiusi e falliscono.

public MemoryStream Get()
{
    var memoryStream = new MemoryStream();

    try
    {
        using (var streamWriter = new StreamWriter(memoryStream))
        {
            // altro codice qui
        }

        return memoryStream;
    }
    catch
    {
        memoryStream.Dispose();
        // eventuale log
        throw;
    }
}

Modificato da scioCoder il 28 febbraio 2019 12:40 -

Alessio
144 messaggi dal 26 febbraio 2007
Grazie mille, adesso torna tutto.


Resta aperta solo la creazione del CSV che non so se ottimizzarla anche li (visto che potrebbe generare anche un file da 1gb). Purtroppo devo per forza generare il CSV a partire da un DataTable...
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,

Purtroppo devo per forza generare il CSV a partire da un DataTable...


Vedo qui che il DataTable lo ottieni da "mDataStore" che credo sia un tuo oggetto di accesso ai dati.

DataTable dt = mDataStore.GetTable(query);


Dovresti invece farti restituire un DataReader, in modo che tu possa leggere una riga alla volta e subito scriverla su un FileStream (non su un MemoryStream).

Se non ti è possibile lavorare con il DataReader, modifica la tua query in modo da introdurre la paginazione, così che il DataTable non contenga mai più di un centinaio di righe alla volta.

ciao,
Moreno

Enjoy learning and just keep making
144 messaggi dal 26 febbraio 2007
Come mai conviene usare il FileStream? Io usavo il MemoryStream, perchè questo CSV non dovrà essere memeorizzato, ma solamente zippato e restituito dalla mia WebAPI.

Per quanto riguarda l'uso del FLush è corretto che ad ogni write venga eseguito?
11.886 messaggi dal 09 febbraio 2002
Contributi

Come mai conviene usare il FileStream? Io usavo il MemoryStream

Dunque... non c'è una soluzione valida in senso assoluto. Ovviamente se hai un server con 256GB di RAM non vale neanche la pena mettersi a ottimizzare la generazione del file zip.
Però, nell'era del cloud e dei microservizi, di solito si tende a usare macchine piccole per abbattere i costi di mantenimento. In questo scenario, e dato che consumare la RAM a ufo mi sembra un peccato un po' come tenere l'acqua aperta mentre ci si lava i denti, potresti sfruttare il disco che è una risorsa più economica e più abbondante rispetto alla RAM.

Quindi con il FileStream fai in modo che il file venga salvato su disco mentre viene processato. Questo ti apre un problema: eliminare i file quando non servono più. I file potresti eliminarli dopo che sono stati serviti al client, ad esempio da un action filter. Qui lo vedi fatto per ASP.NET ma anche con ASP.NET Core è più o meno la stessa cosa.
https://stackoverflow.com/questions/2041717/how-to-delete-file-after-download-with-asp-net-mvc#answer-22640473
Qui la documentazione per ASP.NET Core.
https://docs.microsoft.com/it-it/aspnet/core/mvc/controllers/filters?view=aspnetcore-2.2
Oppure cancelli i file più vecchi di tot ore all'arrivo di una nuova richiesta.

ciao,
Moreno

Enjoy learning and just keep making
144 messaggi dal 26 febbraio 2007
grazie mille, tutto chiaro adesso :)

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.