Blazor wasm file system

[andersson09]

Hi,

Will it be possible to have a virtual file system in interpreted mode, perhaps writing to indexedDB or in memory? If so, are there any plans to implement this?

Thanks

[FilipToth]

Would be amazing to have although, hard to implement. I’m also not sure if there would be any risks.

There's an API that already does that but, I still think it would be beneficial to have it built in.
https://docs.abp.io/en/abp/latest/Virtual-File-System

[FilipToth]

So, you can use this if you want to have a virtual file system: https://docs.abp.io/en/abp/latest/Virtual-File-System. I am not sure whether we’ll try to implement something like this. You can always wrap up a quick API suggestion issue.

[FilipToth]

You need to specify if you want to use the virtual file system so this method:

System.IO.File.ReadAllText(@"C:\Users\Public\TestFolder\WriteText.txt"); 

Should also take one more optional parameter, specifying if you want to use the virtual file system. And as @Fydar already said which I agree with, it wouldn't be a good idea to use System.IO with a virtual file system. Plus, it probably wouldn't get through the API review team because of the mentioned reasons.

[andersson09]

Why does it need an optional parameter? If I executed System.IO.File.ReadAllText it will just give me Platform not supported exception which is not useful.

I still don't understand the reasons to why it's not a good idea.

[FilipToth]

Here're some of the reasons why that is a bad idea. The System.IO.File.ReadAllText() method should work with server-side files.

• It violates the solid design principle. System.IO only interacts with the regular file system.
• We don't want to confuse beginners with virtual file systems in the System.IO API.
• Regular Windows doesn't support a virtual file system, as far as I'm concerned, introducing a virtual file system API into System.IO would just be a lot of work for something not that many users will use in the end because most applications that require virtual file systems already use the previously mentioned library and rewriting it would be a lot of work for not that big of a gain.
• Not all platforms that would throw not supported exception support a virtual file system, eg. mobile.
• If we were to introduce virtual file system support, it would probably be in a new namespace eg. System.IO.Virtual or something along those lines. And it would probably be blazor/asp.net specific.
• You can always wrap up a quick issue. If you believe an API is incomplete or could use some work, head over to the issues tab.

Hope this helped clear up some of your questions.

[andersson09]

First of all thank you for your detailed response :)

Here're some of the reasons why that is a bad idea. The System.IO.File.ReadAllText() method should work with server-side files.

• It violates the solid design principle. System.IO only interacts with the regular file system.

System.IO doesn't interact with a regular file system in Blazor. Currently its throwing an exception making it redundant (useless). Actually it's worse than useless since it prevents existing nuget packages working which depend on it.

• We don't want to confuse beginners with virtual file systems in the System.IO API.

The implementation is only for blazor wasm runtime not the regular. Blazor already has unique implementations e.g. crypto, task scheduling etc.

• Regular Windows doesn't support a virtual file system, as far as I'm concerned, introducing a virtual file system API into System.IO would just be a lot of work for something not that many users will use in the end because most applications that require virtual file systems already use the previously mentioned library and rewriting it would be a lot of work for not that big of a gain.

It's not going to be for windows, it will be only for the blazor wasm runtime. System.IO for windows wont change (https://www.nuget.org/packages/Microsoft.NETCore.App.Runtime.browser-wasm/6.0.0-preview.3.21201.4)

I think a lot of users would want want to use existing nuget packages which work on other runtimes without having to refactor anything that touches System.IO

• Not all platforms that would throw not supported exception support a virtual file system, eg. mobile.

Why would mobile not support it? A basic implementation would be a zip stream / indexeddb which a mobile would support. You could just add a memory cap.

• If we were to introduce virtual file system support, it would probably be in a new namespace eg. System.IO.Virtual or something along those lines. And it would probably be blazor/asp.net specific.

Similar to what I said earlier the System.IO within blazor runtime is specific to blazor

• You can always wrap up a quick issue. If you believe an API is incomplete or could use some work, head over to the issues tab.

Will take a stab at this.

Thanks!

[FilipToth]

Why would mobile not support it? A basic implementation would be a zip stream / indexeddb which a mobile would support. You could just add a memory cap.

Yes, you're right (I was thinking about the implications on mobile and, I couldn't think of any).

Will take a stab at this.

Ok, great! Ping me when you publish the issue. Excited about what comes out of this!

Thanks

[Fydar]

Interestingly; as a part of WebAssembly System Interface^[1] (also known as WASI) we may actually have full file-system support built into WebAssembly that Blazor could utilise^[2].

In my opinion, it would be a good idea to reserve the System.IO file system APIs for actual file systems rather than appropriating them for virtual ones.

---

[1]. 'WebAssembly System Interface' https://github.com/WebAssembly/WASI
[2]. 'Discussion about WASI and Blazor AOT' dotnet/aspnetcore#5466 (comment)

[andersson09]

Doesn't WASI only work for code known at compile time (AOT). In mixed mode it is useful to dynamically run code. System.IO is running under the Blazor wasm runtime in this case and should just work in my opinion rather than throwing a platform not supported exception.

[Fydar]

I believe it could still be possible for code running in the Blazor WASM runtime to call into a module that's compatible with the WASI.

[andersson09]

Yes that definitely seems possible. But my point is more about existing apis working. E.g. Assembly.Load currently works because Blazor is running in interpreted mode. If I'm loading an assembly which has a dependency on System.IO it should be possible to get this working.

Just need to change the System.IO implementation (maybe to something similar to what @FilipToth described above or even a ZIP stream would work)

[FilipToth]

Again @andersson09 as I already said, it won't get through API review because of the existing solutions and the fact that we don't want to have virtual file systems under System.IO. But, you can always wrap up a quick API proposal issue.