Open Smurf-IV opened 3 years ago
I have tried via DownloadBinaryBuffers
and DownloadBase64Buffers
But the calls for each 4MB (or 1MB) byte[] insertion take minutes each so is not performant enough
This is a limitation of blazor and javascript itself I don't think it would be possible to fix browser max blob size. We would need to investigate futher on this.
You may be hitting this
https://stackoverflow.com/questions/28307789/is-there-any-limitation-on-javascript-max-blob-size
I'm using this now.. https://www.meziantou.net/generating-and-downloading-a-file-in-a-blazor-webassembly-application.htm and it works fine.
Interesting article. He is using low level api and seems to gain more performance and less overhead. Thanks for the share. I will be considering changing the implementation in the near future.
I was having an issue with an even smaller size (400kb ish)
I turned my stream into a byte array and it worked.
@arivera12, you might want to impliment this
byte[] myByteArray;
using (var memoryStream = new MemoryStream())
{
originalStream.CopyTo(memoryStream);
myByteArray= memoryStream.ToArray();
}
for your
internal static async Task<byte[]> ToByteArrayAsync(this Stream stream)
{
var streamLength = (int)stream.Length;
var data = new byte[streamLength];
stream.Position = 0;
await stream.ReadAsync(data, 0, streamLength);
return data;
}
I can submit a PR if you need/like
@thalaeg which issue are you having? I don't get what are trying to tell me. This issue is about managing large files which I haven't worked on it yet. if you have another issue please create a new issue.
@arivera12 My issue was when I had a file that was too large (anything above 64ish KBs) the file would become corrupted.
I was downloading excel files (.xlsx extension) via a
await BlazorDownloadFileService.DownloadFile("usaFile.xlsx", usaStream, CancellationToken.None, CancellationToken.None, progress: null);
Where usaStream
was a Stream
.
When I changed usaStream
to a byte[]
via the method above, it worked and was no longer corrupted.
I can't share the file with you because of confidential info in it :(.
that's weird are you using blazor server or blazor wasm?
if you are using blazor server you may be hitting this:
https://docs.microsoft.com/en-us/aspnet/core/signalr/security?view=aspnetcore-3.1#buffer-management
blazor wasm
here is the .csproj
if helpful
<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<EmbeddedResource Include="data\CanadaDivisionCodes.json">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</EmbeddedResource>
<EmbeddedResource Include="data\USADivisionCodes.json">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</EmbeddedResource>
</ItemGroup>
<ItemGroup>
<PackageReference Include="BlazorDownloadFile" Version="2.3.1" />
<PackageReference Include="ClosedXML" Version="0.95.4" />
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="6.0.0" />
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="6.0.0" PrivateAssets="all" />
<PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
<PackageReference Include="System.Net.Http.Json" Version="6.0.0">
<TreatAsUsed>true</TreatAsUsed>
</PackageReference>
<PackageReference Include="MudBlazor" Version="6.0.2" />
</ItemGroup>
<ItemGroup>
<Using Include="System" />
<Using Include="System.Linq" />
<Using Include="System.Threading.Tasks" />
<Using Include="System.Collections.Generic" />
</ItemGroup>
</Project>
What I can think is that I may be having a bug in the stream overload method. I will move this into a new issue.
I have a memory stream that is
280803689
bytes I have direct access to the buffer it contains viavar bytes = ms.GetBuffer();
I then call
DowloadFileResult fileResult = await DownloadFileService.DownloadFile(FileDetails.OriginalFileName, bytes, cts.Token, 1024*64, "application/octet-stream", OnProgress);
Then 6 minutes later I get this:L: GC_MAJOR_SWEEP: major size: 2512K in use: 1523K L: GC_MAJOR: (user request) time 63.28ms, stw 63.30ms los size: 450736K in use: 449168K