Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SQLite provider ResolutionPath fail #818

Closed
FedericoTauto opened this issue Mar 20, 2024 · 8 comments
Closed

SQLite provider ResolutionPath fail #818

FedericoTauto opened this issue Mar 20, 2024 · 8 comments

Comments

@FedericoTauto
Copy link

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
Copy link
Member

Thorium commented Mar 20, 2024

Thanks for reporting this. The only change related to this is the commit f48f7dd 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
Copy link
Author

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
Copy link
Member

Thorium commented Mar 20, 2024

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
Copy link
Author

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
Copy link
Member

Thorium commented Mar 25, 2024

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
Copy link
Author

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
Copy link
Member

Thorium commented Apr 19, 2024

Thanks for the sample repo.
Issue fixed in 1.3.36

@Thorium Thorium closed this as completed Apr 19, 2024
@FedericoTauto
Copy link
Author

Great! Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants