SQLProvider
SQLProvider copied to clipboard
TypeProvider not working with dotnet core 3.0
Description
I'm trying to use the typeprovider with netcoreapp3.0 (3.0.100). But it is not working for me. I alread tried to reference System.Data.SqlClient. Ionide is failing as well.
Repro steps
-
Set up Dotnet core app 3.0
-
Add SqlProvider
-
Try to get datacontext
open FSharp.Data.Sql
open System
open Config
/// Query DME
let [<Literal>] CompileTimeConnectionString = "myconnectionString"
type SqlDme = SqlDataProvider<Common.DatabaseProviderTypes.MSSQLSERVER, ConnectionString=CompileTimeConnectionString, UseOptionTypes=true> //, ContextSchemaPath = ContextSchemaPath>
Expected behavior
TypeProvider should just work
Actual behavior
I get following error message when building the project:
Could not load file or assembly 'System.Data.SqlClient, Version=4.6.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Das System kann die angegebene Datei nicht finden. [C:\Users\tforkmann\Documents\1_Tests\PreveroFeed\src\Server\Server.fsproj]
Known workarounds
- Add FSharp.Compiler.Tools
- Add to fsproj file
<DotnetFscCompilerPath></DotnetFscCompilerPath>
Related information
- MS Sql
- Windows 10
- netcoreapp3.0
Id there a general strategy for type providers in dotnet sdk 3.x? Since we don't get any new fsharp.compiler.tools packages anymore - what's the replacement?
/cc @dsyme @cartermp
Having this same problem on mac.
@forki There is no replacement, as that was never a supported scenario in the first place. I'd encourage never installing that package.
Reality is that this was the only way to get things working. But it's not really important anymore. The question is how can we proceed?
Realistically there's probably a bug in either the type provider, the provider sdk, or F# compiler that needs to be resolved. Using an unsupported package containing a very old .NET Framework-only version of the F# compiler isn't a scenario you should be considering here.
I'm happy to approve PRs (and release new packages). But I know nothing about .NET Core 3.0, I still use .NET Framework. For example I have no clue do you still need to set DotnetFscCompilerPath or not, to resolve the duplicate fsc problem.
This type provider loads DB drivers via reflection (to not depend every DB), which is a challenge in Core as the dependencies are broken down to many dlls that are loaded from unknown cache location.
Here is an example typeprovider from the TypeProvider SDK, referring NETStandard.Library.NETFramework, I guess it's outdated as well. However if you don't do that, loading different versions of .NET strandard.dll will cause a loop in reflection.
Today I worked a bit on the problem.
I created a fork of the sqlprovider and only focused on the netcore version. I got the compile compiling on NetCore 3.0. The only thing missing is that the SqlClient needs to be present before compile time. With the Compiler Tools I didn’t need to add anything. I don’t understand what the compiler tools is doing differently to make the Client available before compile time
For example I have no clue do you still need to set DotnetFscCompilerPath or not, to resolve the duplicate fsc problem.
Nope!
@tforkkmann FWIW I can get this to run seamlessly on Ubuntu 16.04 and OSX using .net core 3.0.100, npgsql and postgres 11 and VS Code as long as I set the resolution paths up from the "unknown cache directory".
I am having lots of issues with SaveContextSchema() though, but I've referenced that elsewhere.
@mcspud Which directory are you adding as a resolution folder? The Package folder?
Hey @tforkmann - yep. I'm using the osx package location,
let [<Literal>] ConnectionString =
"Server=localhost;" +
"Database=jabronis;" +
"User Id=localdev;" +
"Password=password;"
let [<Literal>] DatabaseVendor = Common.DatabaseProviderTypes.POSTGRESQL
let [<Literal>] CaseSensitivityChange = Common.CaseSensitivityChange.ORIGINAL
let [<Literal>] ContextSchemaPath = __SOURCE_DIRECTORY__ + "/.postgres.schema.json"
let [<Literal>] ResolutionPath = @"~/.nuget/packages/Npgsql/4.1.1/lib/netcore3.0"
type Sql =
SqlDataProvider<
ConnectionString=ConnectionString,
DatabaseVendor=DatabaseVendor,
CaseSensitivityChange=CaseSensitivityChange,
ResolutionPath=ResolutionPath>
And from my .fsproj
:
...
<TargetFramework>netcoreapp3.0</TargetFramework>
<ItemGroup>
...
<PackageReference Include="Npgsql" Version="4.1.1" />
<PackageReference Include="SQLProvider" Version="1.1.68" />
</ItemGroup>
That .nuget
path is the default location for .net core
packages on mac.
This all works nicely, but on VSCode intellisense can be pretty flakey often times requiring me to restart it to get it kick back in. It doesn't work at all on Rider for the generative type provider. I also can't successfully export the schema so I can't actually build the project in a docker image on a CI/CD environment lol :)
Hello everyone. I'm new to F# and learning it.
I've solved problem by adding System.Data.SqlClient to project:
<PackageReference Include="System.Data.SqlClient" Version="4.8.0" />
but got this:
The most strange thing - I can create an instance of IAsyncDisposable:
let a = { new IAsyncDisposable with
member __.DisposeAsync() = ValueTask()}
How to make it work?
Configuration
- Dotnet core SDK v3.0.101
- Linux mint 19.1
- Ionide-fsharp 4.3.2
Hi,
I just updated the package to contain System.Data.SqlClient of package 4.8.0 Hopefully helps.
@jl0pd just a guess, sounds like your compile-time version of System.Runtime.dll doesn't match the execution time version of System.Runtime.dll
Hi,
i tried with the new SqlProvider version.
Somehow it still asks for the System.Data.SqlClient version 4.6.1
Can you maybe update the 4.6.1 version as well?
I also saw that the System.Data.SqlClient doesn't has a net core 3.1 version.
We probably need to migrate to Microsoft.Data.SqlClient https://devblogs.microsoft.com/dotnet/introducing-the-new-microsoftdatasqlclient/
System.Data.SqlClient are one of the few which are currently not loaded via reflection...
I think it's version 4.6.1? Or 4.8? Is there a problem? Do you do binding redirects?
I have 4.8 in my paket.lock. Is binding redirects required?
I think I updated it to 4.8, but I may have missed something.
https://github.com/fsprojects/SQLProvider/blob/4d79debfc59fbba1e3fae1e816d1d9309bbfe012/paket.lock#L152
Hmm, ok. Updated to 1.1.82. Still the same errror. Why are you using the FSharp.Compiler.Tools now? Is it still required?
Ok, it's compiling and running but ionide shows that error. Maybe it is just an Ionide issue?!
I was planing to use FSharp.Compiler.Tools because people have here lot of compilation issues and some of them come by using wrong fsc.exe, so I thought maybe the compiler tools would provide a consistent version. However it's not used right now.
I would highly recommend not using FCT. Chiefest of issues being that there will forever be a delta between what you compile with and what your IDE things you're doing.
I'm trying this on macOS. After getting rid of Mono and Visual Studio Mac, with only pure .net code 3.1 SDK installed it started to work.
- I've setup the test project roughly following https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/get-started-command-line.
- added the packages "SQLProvider" and "MySqlConnector" using "dotnet add package"
- seems to work without an explicit ResolutionPath (for MySql)
Visual Studio Code:
- Intellisense with ionide in VSC seems to work ok (db schema changes require a restart)
- Ionide: set "Fsac Runtime" to netcode
- Ionide: set "Use SDK Scripts" to true (so fsi works with .net core)
So it looks like the F# compiler (4.5, outdated anyway) from Mono does not work and mixing mono build environment with .net code runtime environment is a bad idea. All the obviously outdated documentation ("how to get startet with f#") from Microsoft is really irritating.
Hope this helps.
@njeisecke, I'm confused... I thought type providers still need Mono to compile. Has this changed with .NET Core 3.1?
Seems to work. I removed all of the mono stuff and use the "dotnet" command for everything. It builds and runs.
Type Providers have not needed mono to compile for quite a long time. There's no reason to require .NET Framework of any flavor unless you specifically require an API that has no alternative on .NET Standard.
Type Providers have not needed mono to compile for quite a long time.
Wow, cool. :-D All these undocumented features that I'm not aware of.
@njeisecke Could you maybe create a project example? And share it with us? I'm still not able to get SqlClient to work.
Hi,
i tried with the new SqlProvider version.
Somehow it still asks for the System.Data.SqlClient version 4.6.1
Can you maybe update the 4.6.1 version as well?
Hi I am getting this error with Ionide too, on Windows 10, dotnet 3.1. It compiles but Ionide shows the error.
jup!