Cache native libe_sqlite3.so install into Eco's apphost dir #24

New issue

Closed

opened 2026-06-17 07:29:36 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-06-17 07:29:36 +00:00

Owner

Originally filed by @coilysiren on 2026-05-18T06:45:38Z

Problem

Eco's mod loader uses AssemblyLoadContext.Default.LoadFromStream, which doesn't add the mod folder to .NET's native-library search path. So when Microsoft.Data.Sqlite P/Invokes e_sqlite3, the runtime looks in Eco's apphost extraction dir (e.g. ~/.net/EcoServer/<hash>/) and not in Mods/EcoReplay/.

Current workaround: manual symlink:

ln -sf /home/kai/Steam/steamapps/common/EcoServer/Mods/EcoReplay/libe_sqlite3.so \
       /home/kai/.net/EcoServer/oXJfcCrti-5I/libe_sqlite3.so

The hash oXJfcCrti-5I is stable per Eco-binary build but resets when Eco updates.

Next steps

Add an install-mod step (Makefile target) that re-symlinks after every install/Eco-update.
Or: drop Microsoft.Data.Sqlite in favor of a pure-managed SQLite (e.g. dotnet/runtime's built-in System.Data.SQLite once a Linux-native build is in the chain — see the work already done in /tmp during overnight session to build libSQLite.Interop.so from SDS 1.0.119 source).
Or: use SetDllImportResolver more aggressively, called from a module-initializer instead of from Initialize() so it fires before any other code touches Microsoft.Data.Sqlite. The current resolver code is wired up but Eco's pre-init reflection scan likely triggers SqliteConnection's static cctor before my plugin's Initialize runs.

Migrated from coilyco-flight-deck/eco-replay#6 during the eco repo consolidation (coilysiren/inbox#100).

_Originally filed by @coilysiren on 2026-05-18T06:45:38Z_ **Problem** Eco's mod loader uses `AssemblyLoadContext.Default.LoadFromStream`, which doesn't add the mod folder to .NET's native-library search path. So when `Microsoft.Data.Sqlite` P/Invokes `e_sqlite3`, the runtime looks in Eco's apphost extraction dir (e.g. `~/.net/EcoServer/<hash>/`) and not in `Mods/EcoReplay/`. **Current workaround:** manual symlink: ``` ln -sf /home/kai/Steam/steamapps/common/EcoServer/Mods/EcoReplay/libe_sqlite3.so \ /home/kai/.net/EcoServer/oXJfcCrti-5I/libe_sqlite3.so ``` The hash `oXJfcCrti-5I` is stable per Eco-binary build but resets when Eco updates. **Next steps** - Add an `install-mod` step (Makefile target) that re-symlinks after every install/Eco-update. - Or: drop `Microsoft.Data.Sqlite` in favor of a pure-managed SQLite (e.g. `dotnet/runtime`'s built-in `System.Data.SQLite` once a Linux-native build is in the chain — see the work already done in /tmp during overnight session to build `libSQLite.Interop.so` from SDS 1.0.119 source). - Or: use `SetDllImportResolver` more aggressively, called from a module-initializer instead of from `Initialize()` so it fires before any other code touches `Microsoft.Data.Sqlite`. The current resolver code is wired up but Eco's pre-init reflection scan likely triggers `SqliteConnection`'s static cctor before my plugin's `Initialize` runs. --- _Migrated from coilyco-flight-deck/eco-replay#6 during the eco repo consolidation (coilysiren/inbox#100)._

coilysiren added the

label

2026-06-17 07:29:36 +00:00

coilysiren commented

2026-06-17 08:20:39 +00:00

Author

Owner

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: burndown-2026-06.

Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag: `burndown-2026-06`.

coilysiren

2026-06-17 08:20:39 +00:00