Skip to content

PowerSync.Common 0.1.2: extension load fails in .NET Framework host when AppContext.BaseDirectory is non-writable/non-package path #71

@graydonpleasants

Description

@graydonpleasants

We’re integrating PowerSync.Common in a .NET Framework plugin host (Autodesk Civil3D/AutoCAD).
Even with valid native binaries present and manually loadable, PowerSync DB init fails at extension load.

Environment

  • Package: PowerSync.Common 0.1.2
  • Host: .NET Framework plugin loaded into AutoCAD/Civil3D process
  • OS: Windows x64
  • Process architecture: x64

What we see

PowerSyncDatabase.Init() fails with:

Microsoft.Data.Sqlite.SqliteException: SQLite Error 1: 'The specified module could not be found.'

Stack includes:

PowerSync.Common.MDSQLite.MDSQLiteAdapter.LoadExtension(SqliteConnection db)

Key diagnostic findings

  • powersync.dll, e_sqlite3.dll, and sqlite3.dll exist in plugin/runtime/data paths.
  • Manual probe succeeds:
    • LoadExtension(<known good powersync.dll>, "sqlite3_powersync_init") => OK
  • During PowerSync init, resolver still uses host app base:
    • appBase = C:\Program Files\Autodesk\AutoCAD 2027\
    • resolvedPath = C:\Program Files\Autodesk\AutoCAD 2027\runtimes\win-x64\native\powersync.dll
    • exists = false

What we attempted

  • Explicit MDSQLiteDBOpenFactory with MDSQLiteOpenFactoryOptions.SqliteOptions.Extensions:
    • Path = <known good ...\Data\powersync.dll>
    • EntryPoint = sqlite3_powersync_init
  • Also set static/default extension options via reflection fallback.
  • Still fails in MDSQLiteAdapter.LoadExtension, apparently using resolver path from AppContext.BaseDirectory.

Expected behavior

If extension path is explicitly provided via MDSQLiteOptions.Extensions, PowerSync should use that path directly (and not override/fallback to resolver path under host AppContext.BaseDirectory).

Request

Could you confirm whether this is expected in 0.1.2?
If not, could MDSQLiteAdapter.LoadExtension prioritize explicit MDSQLiteOptions.Extensions path(s) over resolver-derived path, especially for plugin-hosted .NET Framework scenarios?

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions