Open ghost opened 3 years ago
Same problem here. Curiously for me this doesn't happen on my development machine. It only happens if I run the build on other Windows 10 PCs. Not sure if perhaps it could be somehow related this? https://forum.unity.com/threads/fallback-handler-could-not-load-library-unity-4-2-osx-10-8-4-standalone.191966/#post-1496078
Interestingly this error also doesn't happen if I build for x86 but only if I build for x86_64 architecture.
I marked this to watch months ago and never figured it out myself. But I believe the reason it works on our development machines is because we have sqlite3 installed somewhere or and made available in our path somewhere. Client machines wouldn't have that and thus they don't work.
We ended up migrating to MySQL for another reason and thus I didn't have to figure this out. But would love the option for sqlite on future projects.
I replaced the sqlite3.dll from Plugins / SQLite / x64 with the latest pre-compiled binary (64-bit DLL) from https://www.sqlite.org/download.html and it fixed the problem.
I replaced the sqlite3.dll from Plugins / SQLite / x64 with the latest pre-compiled binary (64-bit DLL) from https://www.sqlite.org/download.html and it fixed the problem.
Perfect. This works for me aswell. Thank you very much :)
I replaced the sqlite3.dll from Plugins / SQLite / x64 with the latest pre-compiled binary (64-bit DLL) from https://www.sqlite.org/download.html and it fixed the problem.
Solved my problem. Windows standalone build with Mapbox on Windows Server 2019. Thx!
Hi. I am getting this error while trying to run Unity win10 build on other machine with Unity 2021.1.2f.1 (I've tried 2020.3 and 2019.4 - bug persists and I also tried building very original version cloned from this repository - just an example). Please take a look, thank you. Also I am not sure, but why does it use my original file paths from the PC I've built the build? In this line f.e.:
(Filename: C:/chosen-stream/Unity/projects/Sqlite-Test-2019/Assets/Scripts/DataService.cs Line: 23)
And this is quite strange, because the dll itself is indeed within the build files: