Closed genifycom closed 2 years ago
I did try <PublishTrimmed>false</PublishTrimmed>
but the behavior did not change.
I also tried -s ERROR_ON_UNDEFINED_SYMBOLS=0 in emcc-default.rsp as per issue #39528
@genifycom thanks for contacting us.
@SteveSandersonMS do you have any thoughts?
I definitely published the BlazeOrbital demo and verified it works, both with and without AOT compilation, since I was collecting stats on the resulting app size - these numbers were in one of the presentation slides. I didn't encounter any such error.
@genifycom Perhaps there is some configuration difference between your app and the BlazeOrbital demo app. If you can provide a minimal repro case for the fault you're seeing (as a GitHub repo), we'd be able to investigate.
I also tried following the repro steps exactly as given above, on .NET 6.0.1, and didn't encounter any error.
Hi @genifycom. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.
See our Issue Management Policies for more information.
@SteveSandersonMS Here is a sample repo using Sqlite and EFCore and this errors out when publishing the blazor wasm app. Please can you assist?
@fingers10 Could you please confirm whether you've tried to publish the https://github.com/SteveSandersonMS/BlazeOrbital sample, and whether this issue also reproduces for you in that project?
If so, please specify what steps you're following to publish the project, and what error you get. Thanks!
@SteveSandersonMS, I tried with BlazeOrbital and I'm able to publish it. But not with the minimal sample repo using Sqlite and EfCore. When I publish I get the following Error.
I'm using Visual Studio 2022 running on Windows 11.
Please assist on what I'm missing.
It would also be great If you could write/share the steps on how to generate e_sqlite3.o
.
I have noticed from your New Blazor WebAssembly capabilities in .NET 6 video that you're doing emcc sqlite3.c -shared -o e_sqlite3.o
. Following that I have
emcc sqlite3.c -shared -o e_sqlite3.o
, I get emcc
is not recognised as internal or external command. So I just copied the e_sqlite3.o
file from your BlazeOrbital Repository.Do we need to install any additional workload? Please assist. This could help many out there.
@fingers10 The main differences I can see between your app and the BlazeOrbital sample are:
One or both of these is probably responsible for the difference.
However the good news is you don't need to bundle your own e_sqlite3.o file any more and mess with these low-level details, since support is now built into SQLite's NuGet package: https://twitter.com/bricelambs/status/1491134363945570305. Could you try using those packages? Thanks!
@SteveSandersonMS I tried using SQLitePCLRaw.bundle_e_sqlite3
nuget package mentioned in the above link. But still no luck.
Project FIle:
<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="6.0.2" />
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="6.0.2" PrivateAssets="all" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="6.0.2" />
<PackageReference Include="SQLitePCLRaw.bundle_e_sqlite3" Version="2.1.0-pre20220207221914" />
</ItemGroup>
<!--<ItemGroup>
<NativeFileReference Include="Data\e_sqlite3.o" />
</ItemGroup>-->
</Project>
Am I still having any wrong configuration or workload missing in my machine or defining own NativeMethods signatures is the only workaround available now?
If that's the workaround then all methods in that file needs to be added? i.e I need to add a copy of that file in my project?
If you're using the packages that @bricelam is tweeting about, it shouldn't be necessary to add your own NativeMethods definitions.
@bricelam, do you have any thoughts on why this might be failing? Are there instructions anywhere for using SQLite from Blazor WebAssembly since you published those preview packages?
@fingers10 I managed to get it to work after updating to use SQLite's NuGet package
and shifting the AllowUnsafeBlocks
and EmccExtraLDFlags
from Directory.build.props
to the .csproj
file. This is how my .csproj
file looks like after omitting some of my project's specific code.
<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
<EmccExtraLDFlags>-s WARN_ON_UNDEFINED_SYMBOLS=0</EmccExtraLDFlags>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="6.0.1" />
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="6.0.1" PrivateAssets="all" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="6.0.1" />
<PackageReference Include="System.Net.Http.Json" Version="6.0.0" />
<PackageReference Include="SQLitePCLRaw.bundle_e_sqlite3" Version="2.1.0-pre20220207221914" />
</ItemGroup>
</Project>
@Zhiyuan-Amos ,
Adding,
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
<EmccExtraLDFlags>-s WARN_ON_UNDEFINED_SYMBOLS=0</EmccExtraLDFlags>
makes publish to succeed but bring a runtime exception,
Could not find method 'AddYears' on type 'System.DateOnly' System.InvalidOperationException: Could not find method 'AddYears' on type 'System.DateOnly'
@fingers10 yes I encountered that too, but that's a different issue. :P This is the parent issue https://github.com/dotnet/efcore/issues/26288, and a temporary fix can be found here https://github.com/dotnet/efcore/issues/26860.
I managed to resolve it by adding this to my codebase, based on the issue above.
@Zhiyuan-Amos many thanks.. that helped.
@SteveSandersonMS Many thanks for your support. Now I'm able to publish and run with the SQLitePCLRaw.bundle_e_sqlite3
nuget along with the temp fix suggested by @Zhiyuan-Amos .
@bricelam, @SteveSandersonMS Any inputs on fixing this in near future?
@SteveSandersonMS we don't e_sqlite3.a
after publish? I published the demo in gh-pages
- BlazorWasmEfCore and it works without e_sqlite3.a
. Please can you share more inputs on this?
e_sqlite3.a gets statically linked directly to into dotnet.wasm on build. So no, the .a file won't get published.
@bricelam , many thanks for your inputs.
As of now sqlite in blazor fails on publish. The following flags are added as workaround.
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
<EmccExtraLDFlags>-s WARN_ON_UNDEFINED_SYMBOLS=0</EmccExtraLDFlags>
Is it something that will be fixed on upcoming releases?
@ericsink It looks like it's complaining about not finding sqlite3_win32_set_directory
on Wasm. Do you already have workarounds for this on iOS and Android AoT? Or are those linkers just more forgiving by default?
The iOS builds use provider_internal
, which is compiled specially to not look for sqlite3_win32_set_directory
. All other platforms currently allow this. (If Android AoT is a thing, I don't have any support for it yet.)
Anyway, it looks like there is no special TFM for Wasm? If we had something like net6.0-webassembly
, I could just add a provider with that win32 dir feature removed and multi-target for it. But I guess Wasm is more of a RID-level thing that a TargetFramework, isn't it.
Adding it to stubs.c is another approach that should work fine.
Wait -- the stubs.c approach is a little more subtle than that. I'm looking more closely at that approach...
Yeah, we can do the stubs.c thing for sqlite3_win32_set_directory and wasm. We just need to be sure that stub is only included for wasm so it doesn't clash with the real implementation from sqlite itself. Either a separate wasm-only stubs file or inside the existing stubs.c with an ifdef.
Let me know if you want me to make this change, as opposed to trying to find a way of solving it at the provider/TFM level.
NuGet lets you override managed assemblies for a specific RID. The nupkg would look something like this:
(Edited previous comment. Posted too soon.)
The RID-specific assembly is more work, but would probably be the better option. We could even reverse it and make the one with sqlite3_win32_set_directory
specific to windows.
I think that would look something like this:
This may allow iOS to not require a separate provider.
I'll take a closer look at the RID-specific lib approach. Unfortunately, I recently changed those providers to use csproj-style "dotnet pack generates the nuspec from the csproj" instead of a nuspec file, because it seems like that's the direction they want everyone to go. But unless there is a way to do these RID-specific assemblies in csproj (which I doubt), I'll need to go backward on that.
(Pretty sure iOS will always need that special provider anyway, because it does the DllImport("__Internal")
trick.)
Hello @SteveSandersonMS, I tried updating my Blazor Wasm app to run .NET 7 Preview 2 with both <PackageReference Include="SQLitePCLRaw.bundle_e_sqlite3" Version="2.1.0-pre20220207221914" />
and <PackageReference Include="SQLitePCLRaw.bundle_e_sqlite3" Version="2.1.0-pre20220318192836" />
, however I'm encountering the following error at this line.
Uncaught ReferenceError: FS is not defined
(this is probably the wrong thread for me to ask you this, please feel free to direct me to a more appropriate place for further discussion, thank you!)
@Zhiyuan-Amos It looks like this is due to a change in the runtime. Would you mind filing an issue at https://github.com/dotnet/runtime, indicating clearly that this is related to WebAssembly?
@lewing Not sure if it's intentional to remove the FS
JS API. It would be good to discuss next week and make sure that, if we're having a breaking change here, we have some way to communicate it and perhaps allow passing some Emscripten flags to restore the FS
APIs if relevant.
@SteveSandersonMS the issue has been resolved following https://github.com/dotnet/runtime/issues/67290#issuecomment-1098865533, fyi :)
Is there an existing issue for this?
Describe the bug
Create a default Blazor WebAssembly App project. Configure for HTTPS only.
This project runs successfully in both Debug and Release mode.
Now add a Folder Data and place in there the e_sqlite3.o file from Steve Sandersons demo.
Add to the Project file the line in Item Group
<NativeFileReference Include="Data\e_sqlite3.o" />
Now the project will run in Debug mode, but in Release mode it gets an error as follows:
blazor.webassembly.js:1 Assertion failed: Cannot call unknown function mono_wasm_set_is_debugger_attached, make sure it is exported
This means that we cannot use Hot Release (currently only runs in Release mode) with a native file.
Expected Behavior
Native Files should be useable in both Debug and Release mode.
Steps To Reproduce
Described above
Exceptions (if any)
blazor.webassembly.js:1 Assertion failed: Cannot call unknown function mono_wasm_set_is_debugger_attached, make sure it is exported
.NET Version
Anything else?
.NET SDK (reflecting any global.json): Version: 6.0.101 Commit: ef49f6213a
Runtime Environment: OS Name: Windows OS Version: 10.0.19043 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\6.0.101\
Host (useful for support): Version: 6.0.1 Commit: 3a25a7f1cc
.NET SDKs installed: 3.1.406 [C:\Program Files\dotnet\sdk] 5.0.103 [C:\Program Files\dotnet\sdk] 5.0.202 [C:\Program Files\dotnet\sdk] 5.0.300 [C:\Program Files\dotnet\sdk] 5.0.301 [C:\Program Files\dotnet\sdk] 6.0.100 [C:\Program Files\dotnet\sdk] 6.0.101 [C:\Program Files\dotnet\sdk]
.NET runtimes installed: Microsoft.AspNetCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 5.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft Visual Studio Community 2022 (64-bit) Version 17.0.5