Aligned Versions for Blazor.FileSystemAccess

[warappa]

First thank you for your library!

Unfortunately, I run into major problems. I tried to use the latest version (3.3.0). Loading files from a directory works, but then the writing of files fail (see exception 1 below). Then I tried to update the dependencies (especially Blazor.Streams) but then MissingMethodExceptions or other incompatibilities started to pop up on loading.
Since yesterday I try to get a combination that works for reading and writing.

What is the most-up-to-date combination of the following libraries?

• KristofferStrube.Blazor.FileAPI
• KristofferStrube.Blazor.FileSystem
• KristofferStrube.Blazor.FileSystemAccess
• KristofferStrube.Blazor.Streams
• KristofferStrube.Blazor.WebIDL

I think I need higher Blazor.Streams library, but that breaks other stuff.
Especially these fixes look like what I would need:
KristofferStrube/Blazor.Streams#3
KristofferStrube/Blazor.Streams#23

As you were releasing new versions of your other libraries in the last few days, do you plan to update this also in the near future?

Exception 1:

System.ArgumentException: Argument_DestinationTooShort Arg_ParamName_Name, destination
   at KristofferStrube.Blazor.Streams.ReadableStream.ReadAsync(Memory`1 buffer, CancellationToken cancellationToken)
   at System.IO.Stream.<CopyToAsync>g__Core|29_0(Stream source, Stream destination, Int32 bufferSize, CancellationToken cancellationToken)

[KristofferStrube]

Hey @warappa 😊

Thanks for your interest in the library. You are correct in spotting that I’ve been updating the dependencies of this project. And it is exactly with the goal of updating this project. I plan to release a new version very soon which would target all the newest versions of my other libraries. That does include some breaking changes, so it will be a major release which I also want to document some migration guides for.

I think the problem your exception hints to has been fixed in a newer version of Blazor.Streams, which we will soon also target. But if you would be able to supply some sort of minimal reproducible project. Then I would love to test it with the non-released version. To make sure that it will work with your use case once I release.

I accidentally made a breaking change in Blazor.WebIDL a long time ago which defines the structure of all my wrapper types which is the reason why you can’t cherry pick other versions of the up-stream dependencies. That is something I’ve been working on fixing since.

[warappa]

It's not easy to provide a full reproduction, due to private code and how hard it is to find which combinations caused what issues. But here are the code snippets that fail.

In one combination

var fileHandle = await FileSystemAccessService.ShowDirectoryPickerAsync();

throws an exception (FileNotFoundException don't know why, but only after being used a few lines after!?!).

In another combination (only referencing FileSystemAccess 3.3.0):

var writeHandle = await fileHandle.CreateWritableAsync(new KristofferStrube.Blazor.FileSystem.FileSystemCreateWritableOptions
{
    KeepExistingData = false
});

await writeHandle.WriteAsync(stringContent); // throws here
await writeHandle.CloseAsync();

throws a MissingMethodException.

Uncaught (in promise) Error: System.MissingMethodException: Method not found: void KristofferStrube.Blazor.Streams.WritableStream..ctor(Microsoft.JSInterop.IJSRuntime,Microsoft.JSInterop.IJSObjectReference)
   at KristofferStrube.Blazor.FileSystem.FileSystemWritableFileStream.CreateAsync(IJSRuntime jSRuntime, IJSObjectReference jSReference)
   at KristofferStrube.Blazor.FileSystem.FileSystemFileHandle.CreateWritableAsync(FileSystemCreateWritableOptions fileSystemCreateWritableOptions)

And in yet another combination, copying FileHandle content to a ZipArchiveEntry Stream, throws the exception shown above:

using var zipStream = new MemoryStream();

using (var archive = new ZipArchive(zipStream, ZipArchiveMode.Create, leaveOpen: true))
{
    foreach (var kvp in fileKeyValues)
    {
        var fileUploadInput = kvp.Value.FileUploadInput;

        var entry = archive.CreateEntry(kvp.Key);

        using var entryStream = await entry.OpenAsync();
        using var fileStream = await fileUploadInput!.File.StreamAsync();
        fileStream.Position = 0;

        await fileStream.CopyToAsync(entryStream); // throws here
    }
}

EDIT:
This package combination leads to another exception:

    <PackageReference Include="KristofferStrube.Blazor.FileAPI" Version="0.4.0" />
    <PackageReference Include="KristofferStrube.Blazor.FileSystem" Version="0.4.0-alpha.2" />
    <PackageReference Include="KristofferStrube.Blazor.FileSystemAccess" Version="3.3.0" />
    <PackageReference Include="KristofferStrube.Blazor.Streams" Version="0.5.0" />
    <PackageReference Include="KristofferStrube.Blazor.DOM" Version="0.3.0" />
    <PackageReference Include="KristofferStrube.Blazor.WebIDL" Version="0.6.0" />

This code throws at GetNameAsync()

public static async Task<IEnumerable<(string FullPath, FileSystemFileHandle Handle)>> LoadDirectoryHandlesAsync(
    FileSystemDirectoryHandle dirHandle,
    string currentPath = "")
{
    var results = new List<(string FullPath, FileSystemFileHandle Handle)>();

    var entries = await dirHandle.ValuesAsync();

    foreach (var entry in entries)
    {
        if (entry is FileSystemFileHandle fileHandle)
        {
            var fileName = await fileHandle.GetNameAsync();

            results.Add((GetFilePath(currentPath, fileName), fileHandle));
        }
        else if (entry is FileSystemDirectoryHandle subDir)
        {
            var dirName = await subDir.GetNameAsync(); // throws here
            var dirPath = string.IsNullOrEmpty(currentPath)
                ? dirName
                : $"{currentPath}/{dirName}";

            foreach (var item in await LoadDirectoryHandlesAsync(subDir, dirPath))
            {
                results.Add(item);
            }
        }
    }

    return results;
}

EDIT 2: This may be still related to ShowDirectoryPickerAsync() - it's confusing...

JS object instance with Id '15' does not exist. It may have been disposed.
blazor.web.b9228eflpl.js:1 Error: JS object instance with Id '15' does not exist. It may have been disposed.
blazor.web.b9228eflpl.js:1     at https://localhost:7046/_framework/blazor.web.b9228eflpl.js:1:7502
blazor.web.b9228eflpl.js:1     at https://localhost:7046/_framework/blazor.web.b9228eflpl.js:1:2806
blazor.web.b9228eflpl.js:1     at Array.reduce (<anonymous>)
blazor.web.b9228eflpl.js:1     at Array.<anonymous> (https://localhost:7046/_framework/blazor.web.b9228eflpl.js:1:2791)
blazor.web.b9228eflpl.js:1     at JSON.parse (<anonymous>)
blazor.web.b9228eflpl.js:1     at v (https://localhost:7046/_framework/blazor.web.b9228eflpl.js:1:2773)
blazor.web.b9228eflpl.js:1     at b.processJSCall (https://localhost:7046/_framework/blazor.web.b9228eflpl.js:1:4409)
blazor.web.b9228eflpl.js:1     at b.beginInvokeJSFromDotNet (https://localhost:7046/_framework/blazor.web.b9228eflpl.js:1:4129)
blazor.web.b9228eflpl.js:1     at Object.Xr [as invokeJSJson] (https://localhost:7046/_framework/blazor.web.b9228eflpl.js:1:176669)
blazor.web.b9228eflpl.js:1     at https://localhost:7046/_framework/dotnet.runtime.peu2mfb29t.js:3:34586
blazor.web.b9228eflpl.js:1 Failed to execute 'showDirectoryPicker' on 'Window': The user aborted a request.
blazor.web.b9228eflpl.js:1 AbortError: Failed to execute 'showDirectoryPicker' on 'Window': The user aborted a request.

[warappa]

Also maybe worth mentioning: I'm on .NET 10.

[KristofferStrube]

I'm pretty close to merging a PR for this (#60) which includes the major things I want to have for the next major release.

Would you be able to pull it down locally and target that version for your project to see if it fixes your problem? :)

[warappa]

It Works! 🥳

With this branch's code, everything works! Thank you! 🙏

Unsolicited Feedback

One bit of unsolicited feedback:
disposePreviousValueWhenMovingToNextValue is pretty sublte and easy to miss (just took me some time to figure out). There is (almost?) nothing in the BCL that does that, so it's uncommon for .NET devs.

Change Default

One option could be changing the default to false and therefore let devs opt-in. But this could lead to undisposed disposables piling up.

Fluent API

Maybe better, use fluent syntax opt-in and remove disposePreviousValueWhenMovingToNextValue:

dirHandle.EntriesAsync().WithValueDisposal()

EntriesAsync() then doesn't dispose the elements, but WithValueDisposal() lets you opt-in (could be a generic async disposal wrapper). The intellisense documentation for EntriesAsync() could reference WithValueDisposal(), so it's more visible.

Enum

Another option would be an enum like

public enum EnumerationValueDisposeMode
{
    NoDispose,
    Dispose
}

So it becomes:

dirHandle.EntriesAsync(EnumerationValueDisposeMode.Dispose)

No Default Value

Generally, it would be better to not having a default value for disposePreviousValueWhenMovingToNextValue (or alikes) so in every call the caller has to explicitly specify the behavior he wants.

[KristofferStrube]

Awesome.

Good feedback as well. My primary reason for the decision was that I would rather have you not leak the object references by default. This also aligns with how my event listeners work, where I dispose your events for you (here you don’t have a choice). I do like your idea about making it an explicit choice whether it should auto-dispose or not. Also making an enum so that it is self-descriptive. These extension methods reside in Blazor.WebIDL. I will create an issue for implementing that API in the future. Thanks for the input.