Hi @Chriztiaan, here's what I found while digging into the "Ensure the PowerSync core SQLite extension is loaded" error from my earlier comment. Two separate Unity-specific problems, both need a custom adapter to work around:

1. Native library path resolution

PowerSyncPathResolver.GetNativeLibraryPath(AppContext.BaseDirectory) (used by LoadDefaultPowerSyncExtension) assumes the standard dotnet build/publish output layout, where MSBuild's NuGet targets copy the package's runtimes/{rid}/native/* payload next to the app. Unity never runs that pipeline. Under NuGetForUnity, the package (and its native binaries) end up wherever Unity restored it (e.g. Assets/Packages/PowerSync.Common.x.x.x/runtimes/...), and AppContext.BaseDirectory inside the Unity Editor/Player points somewhere else entirely (Unity's own runtime folder). So the default lookup can never find libpowersync.

2. SqliteConnection.LoadExtension() itself doesn't work under Unity's embedded Mono

Even after pointing at the correct file, Microsoft.Data.Sqlite.SqliteConnection.LoadExtension(path, entryPoint) fails with a generic, empty SQLite Error 1: '' — for a valid file, a correct architecture (verified via file/nm), a valid ad-hoc code signature, and even for the exact same file that's confirmed loadable. I bypassed the ADO wrapper and confirmed via sqlite_version()/compile_options that the correct bundled e_sqlite3 native library is loaded (not some crippled system one), and that the same blank error occurs for a bogus nonexistent path — meaning the C# .LoadExtension() call path itself is broken under Mono here, before it even gets to opening the file.

The fix: use the SQL-level function instead of the C# method:

using var cmd = db.CreateCommand();
cmd.CommandText = "SELECT load_extension(@path, @entryPoint)";
cmd.Parameters.AddWithValue("@path", path);
cmd.Parameters.AddWithValue("@entryPoint", entryPoint);
cmd.ExecuteNonQuery();

This works every time. Interestingly, MAUISQLiteAdapter.LoadExtensionApple already does exactly this (SELECT load_extension(...) instead of .LoadExtension()) for iOS/MacCatalyst — I suspect it's hitting the same kind of platform-specific ADO quirk there.

Because of #1, a Unity-specific adapter is basically mandatory — there's no way to make AppContext.BaseDirectory-based resolution work generically across Editor vs. standalone builds vs. platforms, so the app needs to hand PowerSync.Common the correct native library folder itself. Since MDSQLiteAdapter.LoadExtensions/LoadDefaultPowerSyncExtension are protected virtual, this is doable today without forking the library — sharing what I ended up with as a sample:

UnityMDSQLiteAdapter.cs:

using Microsoft.Data.Sqlite;

using PowerSync.Common.Client;
using PowerSync.Common.DB;
using PowerSync.Common.MDSQLite;
using PowerSync.Common.Utils;

// Two Unity-specific problems, both handled here:
//
// 1. Unity doesn't run the MSBuild/NuGet steps that copy PowerSync.Common's
//    runtimes/{rid}/native/* payload next to the built app, so the base class's
//    AppContext.BaseDirectory-based lookup (LoadDefaultPowerSyncExtension) can't
//    find libpowersync. The caller passes in the actual package folder instead
//    (see PowerSyncPackagePath below) since only the calling script knows how
//    Unity laid it out (Assets/Packages in the Editor, StreamingAssets/a native
//    Plugins folder in a standalone build, etc).
//
// 2. Microsoft.Data.Sqlite.SqliteConnection.LoadExtension() fails with a generic,
//    empty "SQLite Error 1: ''" under Unity's embedded Mono runtime, even though
//    the exact same file loads fine via the SQL-level load_extension() function.
//    PowerSync's own MAUISQLiteAdapter.LoadExtensionApple works around the same
//    kind of platform quirk on iOS/MacCatalyst the same way.

public class UnityMDSQLiteAdapterOptions : MDSQLiteAdapterOptions
{
    // Folder passed to PowerSyncPathResolver.GetNativeLibraryPath — the flattened
    // folder containing libpowersync directly, or the parent of runtimes/{rid}/native.
    public string PowerSyncPackagePath { get; set; } = null!;
}

public class UnityMDSQLiteAdapter : MDSQLiteAdapter
{
    public UnityMDSQLiteAdapter(UnityMDSQLiteAdapterOptions options) : base(options)
    {
    }

    protected override void LoadExtensions(SqliteConnection db)
    {
        db.EnableExtensions(true);

        if (resolvedOptions.LoadPowerSyncExtension)
        {
            LoadDefaultPowerSyncExtension(db);
        }

        foreach (var extension in resolvedOptions.Extensions)
        {
            LoadExtensionViaSql(db, extension.Path, extension.EntryPoint);
        }
    }

    protected override void LoadDefaultPowerSyncExtension(SqliteConnection db)
    {
        // `options` is the base class's protected field; it's already assigned to
        // our UnityMDSQLiteAdapterOptions instance by the time this runs (the base
        // constructor sets it before calling Init(), which triggers this).
        var packagePath = ((UnityMDSQLiteAdapterOptions)options).PowerSyncPackagePath;
        var path = PowerSyncPathResolver.GetNativeLibraryPath(packagePath);
        LoadExtensionViaSql(db, path, "sqlite3_powersync_init");
    }

    private static void LoadExtensionViaSql(SqliteConnection db, string path, string? entryPoint)
    {
        using var cmd = db.CreateCommand();
        cmd.CommandText = "SELECT load_extension(@path, @entryPoint)";
        cmd.Parameters.AddWithValue("@path", path);
        cmd.Parameters.AddWithValue("@entryPoint", entryPoint);
        cmd.ExecuteNonQuery();
    }
}

public class UnityMDSQLiteOpenFactoryOptions : MDSQLiteOpenFactoryOptions
{
    public string PowerSyncPackagePath { get; set; } = null!;
}

public class UnityMDSQLiteDBOpenFactory : ISQLOpenFactory
{
    private readonly UnityMDSQLiteOpenFactoryOptions options;

    public UnityMDSQLiteDBOpenFactory(UnityMDSQLiteOpenFactoryOptions options)
    {
        this.options = options;
    }

    public IDBAdapter OpenDatabase()
    {
        return new UnityMDSQLiteAdapter(new UnityMDSQLiteAdapterOptions
        {
            Name = options.DbFilename,
            SqliteOptions = options.SqliteOptions,
            PowerSyncPackagePath = options.PowerSyncPackagePath
        });
    }
}

And building the factory from a MonoBehaviour, passing in the resolved package path explicitly (this is the part that has to live app-side, since only the app knows how the native lib was laid out for the current platform/build):

private static UnityMDSQLiteDBOpenFactory CreateOpenFactory(string dbPath)
{
    var powerSyncPackagePath = Path.Combine(Application.dataPath, "Packages", "PowerSync.Common.0.1.4", "runtimes", "osx-arm64", "native");

    return new UnityMDSQLiteDBOpenFactory(new UnityMDSQLiteOpenFactoryOptions()
    {
        DbFilename = dbPath,
        PowerSyncPackagePath = powerSyncPackagePath
    });
}

With this, Db.Connect(...) works in the Editor on macOS (Apple Silicon) for me. Note the osx-arm64 folder segment and Application.dataPath are hardcoded for my current Editor setup — for a real standalone build you'd need to resolve this per-platform (probably shipping the native lib via StreamingAssets or a native Plugins folder and resolving from there instead).

On NuGet as a distribution path for Unity: I don't think consuming PowerSync.Common directly via NuGet (even through NuGetForUnity) is going to be a good experience long-term. All native binaries for every RID land in the project unfiltered (nothing strips it down to the platform Unity is actually targeting), NuGetForUnity doesn't apply the MSBuild-time RID selection that dotnet build normally does, and it also produced duplicate/conflicting assembly versions during restores in my testing (had to manually pin Microsoft.Data.Sqlite/SQLitePCLRaw back to the versions PowerSync.Common was actually built against after an unrelated update pulled in newer majors and broke things in confusing ways). My suggestion would be a dedicated Unity package (UPM) that ships pre-sorted native plugins per platform with correct Unity plugin importer settings, plus something like the adapter above built in, rather than expecting NuGetForUnity to do the right thing generically.

Since Unity operates in a Mono environment, it lacks built-in support for libraries like Microsoft.Extensions and Dapper, leading to "dependency hell."

Although it is currently in beta, I hope the package management becomes more streamlined in the future.

Because Unity relies on IL2CPP-based native compilation, it is quite common to encounter situations where certain dependencies are not supported.

Uh oh!

Unity Compatible #93

Description

Summary

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions