Last Updated: 11 Nov 2023 09:09 by ADMIN
Release 5.0.0 (15 Nov 2023) (R1 PI1)


I'm trying to add image previewing to our .Net 6.0.8 Blazor Wasm app using the Telerik Blazor UI FileSelect component. I'd like to be able to create a local url for previewing and also hold onto the file's contents for saving later. There currently doesn't seem to be any great examples/references for doing this using the Telerik FileSelect locally. So, I started looking at the official MS Blazor documentation around images, file uploads and downloads - the most relevant content seemed to be around giving a file's stream to a DotNetStreamReference, then handing it off to JS interop to create a URL from a Blob.

It was already quite slow when testing with a 4KB~ image, but became absolutely unusable once testing things with a larger 4MB~ image. To rule out the Telerik FileSelect's involvement I started testing with the native Blazor FileInput component. I noticed that the sending the DotNetStreamReference to JS interop took a long time itself and learned that .Net 6 added the ability to pass a byte[] almost instantly to JS interop. I was then able to see image previews quickly using the native FileInput component while hosting a file from a byte[]. With this new knowledge in hand I attempted to migrate this new workflow over to the Blazor FileSelect component, but unfortunately there doesn't seem to be a faster way to get a byte[] from the FileSelectFileInfo's Stream.

I'm seeing similar performance issues between the native FileInput using a stream and the Telerik FileSelect using a stream or byte[]. These are both taking around 4-5 minutes to host a file with a locally generated url and preview the image. In contrast I'm seeing wait times around 3-12 seconds using the native FileInput/IBrowserFile, this

byte[] iBrowserFileBytes = new byte[iBrowserFile.Size];
await iBrowserFile.OpenReadStream(maxFileSize).ReadAsync(iBrowserFileBytes);

Please see the attached Blazor Wasm code to recreate the issue. I've included 6 file inputs to test out the difference in performance between each scenario, but the most important file input is the "Blazor InputFile - HostFromByteArray" which shows the most promise. Attached is also the larger file that I was testing against. This might be a bug or maybe I'm just not reading from the FileSelectFileInfo's Stream in the most efficient way.

The only relevant code not attached is likely just this one from Program.cs:

// ...
builder.Services.AddSingleton<IJSInProcessRuntime>(services => (IJSInProcessRuntime)services.GetRequiredService<IJSRuntime>());
// ...
Last Updated: 23 Oct 2023 11:29 by ADMIN
Release 5.0.0 (15 Nov 2023) (R1 PI1)

When the Multiple parameter is set to false, it should restrict the user to selecting only one file. However, the user can still select and upload multiple files if they are dragged.


To reproduce the problem open the following REPL and try to drag a few files in the FileSelect.


Last Updated: 29 May 2023 11:12 by ADMIN


We have found a strange issue that I have created a REPL to reproduce:

1. Select a .doc file

2. Select a second file

3. Click the "Copy Memory Stream" Button

the method stops at CopyToAsync for the .doc file

It seems to work fine if the files are selected together or if different file types are used

I have been testing with the attached .doc and a blank .txt file