Can EF Core work on Blazor WASM?

[ebekker]

I'm exploring weather or not EF Core might work in the Blazor WASM environment.

My theory is that EF Core is a .NET Standard 2.0/2.1 compatible framework, and coupled with a provider that is likewise .NET Standard compatible and does not require any networking or file I/O features that conflict with the browser sandbox, such as the InMemory provider, then it should theoretically be possible to use EF Core "in the browser" with Blazor WASM.

To explore, this theory I created a very basic sample EF Core model and DB context to be hosted in a sample Blazor WASM app, but even very basic invocation of the framework causes low-level errors. I believe these are errors that fundamentally must be addressed by the WASM platform, which is why I have opened an issue in the mono repo, but I also wanted to inquire with the EF Core team if there are any fundamental features that EF Core relies on that would naturally not be available in a Blazor environment.

Issue 17799 in the mono repo referenced above, contains the code snippet for the basic example I'm working with.

[ajcvickers]

/cc @bricelam

[bricelam]

Those clever folks working on Uno got it working in this sample on WASM. They had to build SQLite for WASM (in nventive/Uno.sqlite-wasm) and add a custom SQLitePCL.raw provider (in nventive/Uno.SQLitePCLRaw.Wasm), but it proves that it's all possible.

We're working with the Blazor team to figure out the best path forward.

[ebekker]

I have tested this out with the latest preview version of Blazor WASM (Preview Version 2) and the latest released version of EF Core (Microsoft.EntityFrameworkCore.InMemory Version 3.1.2) and this now works!

I'm assuming this has to do with either updates in mono that Blazor relies on for WASM support, or within changes to Blazor WASM itself.

[Pinox]

@ebekker , are you saying that Sqlite also works now ??

[ebekker]

I didn't try SqlLite, I was just trying with the InMemory provider because for my scenario, I'm planning on creating a custom provider derived from InMemory.

[KuraiAndras]

I have just found this project. It uses the browser's local storage as the database. The key in the local storage is the table name, and the value is the contents of that table in json. Although it might have some caveats but for now it seems as a nice workaround an official provider arrives.

[ebekker]

This is very cool, thanks for the reference!

My scenario is a bit different still -- I'm looking to derive a client-side EF Core provider, which I was going to base on the InMemory provider, but instead of actually persisting to local browser storage (as in the case of the EFCore.LocalStorage project you referenced), my approach is to translate all the calls to a remote OData source.

The idea is to leverage entity tracking on the client and be able to translate LINQ expressions to the roughly equivalent OData service call. OData 4 is rich enough that I think it should be able to handle most expression scenarios and batching based on tracked client-side entities being persisted. But just a brief glance at the code in the EFCore.LocalStorage project, it looks like there's definitely some good ideas I can borrow from there. Thanks again!

[bricelam]

@JeremyLikness got Cosmos DB working in Blazor WebAssembly!

[JeremyLikness]

@ebekker did it work in Release mode, or just Debug? My Cosmos DB solution has issues in release mode and I'm trying to narrow down what area to focus on and whether I need a separate issue. I suspect Release ILinker is optimizing out some necessary code.

[ebekker]

@JeremyLikness , you are correct -- I tried to run my InMemory test in Release mode and it bombed out. I then messed around with the Linker settings as per here and here and sure enough if I always enable linking then even Debug fails and if I always disable linking then Release works.

I then tried some very rudimentary and broad tweaking of the linker by excluding linking on various combinations of assemblies, starting with core Microsoft.EntityFrameworkCore, Microsoft.EntityFrameworkCore.Abstractions and the InMemory assembly, and then broadening to more and more of their dependencies, and while the location and specific error changed a few times, it still ultimately failed.

Looks like this will require a bit more investigation. I wonder if there is some way to analyze or record the superset of all loaded assemblies and types in a running program generated with the linker disabled, then generate a linker config of all the assemblies, types and members that are used. It may not capture everything but it's at least a starting point.

[roji]

Removing from milestone to discuss what else needs to be done

[ajcvickers]

We have a working sample that runs EF Core in Blazor WASM using the Cosmos provider. We will be updating docs/blogs with this information. However, EF Core currently requires that the linker be set not to strip out unused code--issue #21099 is now tracking this. #21101 is tracking making this work with SQLite.