SQLite provider ResolutionPath fail

[FedericoTauto]

Describe the bug Since version 1.3.28, SQLite provider does not resolve the path to the dll. An error is raised:

"error FS3033: The type provider 'FSharp.Data.Sql.SqlTypeProvider' reported an error: Cannot create connection, db driver raised exception: Could  
not load file or assembly 'SQLitePCLRaw.core, Version=2.1.6.2060, Culture=neutral, PublicKeyToken=1488e028ca7ab535'. The system cannot find the file specified."

To Reproduce

let [<Literal>] private ResolutionPath = @"libs/win-x64"

    type sqLite = SqlDataProvider<
        Common.DatabaseProviderTypes.SQLITE,
        SQLiteLibrary = Common.SQLiteLibrary.MicrosoftDataSqlite,
        ConnectionString = ConnectionString, 
        CaseSensitivityChange = Common.CaseSensitivityChange.ORIGINAL,
        ResolutionPath = ResolutionPath,
        UseOptionTypes=Common.NullableColumnType.OPTION>

If the project references SQLProvider <=1.3.27, the above code compiles correctly. If the project references a later version it fails to compile (see error above). Notice that one needs to run dotnet clean when switching versions to see the change in behaviour.

Expected behavior The dlls should be found in the ResolutionPath.

Desktop (please complete the following information):

• OS: Windows 11
• SQLProvider Version: >= 1.3.28

Workaround The code compiles if the required dlls are placed in the same folder as the source file (default resolution path?).

[Thorium]

Thanks for reporting this. The only change related to this is the commit f48f7ddc293cd6e59b56082d73939704a78a71ed to support ; in resolution path so that you can feed multiple resolution paths. It shouldn't change the single-path-case at all, but apparently it has.

I don't totally follow the workaround. Where is your SQLitePCLRaw.core ?

[FedericoTauto]

If I place the SQLitePCLRaw.core and the other dlls in the same folder as the project file and source file it works. If I move them to the ResolutionPath folder it does not work. Is there a default resolution path where the provider looks for the files?

[Thorium]

The default resolution path should be what you defined, however a few things to consider:

Is this script (fsx) or a project (fs)?

For projects, the resolution path should be used in design-time/compile-time only and runtime the files should be copied to the bin-folder (e.g. by adding them as reference files or any other way) because it doesn't make sense to look resolution path from compiled code.

For scripts it doesn't matter so much, but I guess more the question is, have you given a relative path like "./mylibs" or an absolute path like __SOURCE_DIRECTORY__ + "/mylibs", because the scripts are sometimes executed in weird temp project paths.

[FedericoTauto]

I am using a project, and the error is raised at compile-time. I have also tried to exchange the path with __SOURCE_DIRECTORY__ + "/libs/win-x64" but no success

[Thorium]

Would you have a sample repo, I could try with my Mac at some point? The database file name is in the connection string. Do you have full path there or no?

Edit: sorry, just noticed this is Windows 11. But I'm still unable to reproduce this, your code works perfectly.

[FedericoTauto]

Hi @Thorium. Sorry it took a while to respond, I got very busy at work with other stuff. I created a repo here that you should be able to use to reproduce the issue.

[Thorium]

Thanks for the sample repo. Issue fixed in 1.3.36

[FedericoTauto]

Great! Thanks!