Project with target netcoreapp2.0 will not build with SQLProvider package version 1.1.38.

[ScottHutchinson]

Description

OS: Windows
Database: Microsoft SQL Server

Program.fs(8,11): error FS3033: The type provider 'FSharp.Data.Sql.SqlTypeProvider' reported an error: Could not load file or assembly 'System.Data.SqlClient, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Known workarounds

After running the command below, the project builds and runs with either System.Data.SqlClient package version 4.4.0 or 4.4.3.

dotnet add package SQLProvider --version 1.1.26

[Thorium]

We need a bit more description here:

• What database?
• What operating system?

[ScottHutchinson]

I hope this repo will help, but you will probably need to run dotnet restore to install the 2 nuget packages listed in the .fsproj file.

https://github.com/ScottHutchinson/sqlprovider-dotnetcore-demo/tree/mcve

[Thorium]

It seems that you don't have the FscToolPath and FscToolExe set in the projects. They were needed at least a month ago. I don't know if this has changed since as .NET Standard/Core seems to change quite often.

[ScottHutchinson]

I do too. Make sure you are looking at the mcve branch, not the master branch.

https://github.com/ScottHutchinson/sqlprovider-dotnetcore-demo/blob/mcve/sqlprovider-dotnetcore-console/sqlprovider-dotnetcore-demo.fsproj#L6

[Thorium]

To produce .NET Standard code you have to use net451 version of SQLProvider on compile time and then you can use the correct version on runtime. That is how typeproviders currently work, and sadly that needs some manual configuration for .NET Standard projects.

fsprojects/FSharp.TypeProviders.SDK#182 (comment)

Duplicate: #534

[ScottHutchinson]

@Thorium But why does it work simply by changing the version from 1.1.38 to 1.1.26 ??

[nikonthethird]

Thank you @ScottHutchinson, that totally fixed it for me as well.

I see the same thing: After updating my Paket dependencies the build suddenly failed with the same error message as Scott described. I have the Fsc configuration set up in my .fsproj file, but it didn't matter, the build failed anyway.

I am on Windows using the latest version of .NET core.

[Thorium]

Created PR to the repo.
Clearly we need to add more documentation for the .NET Standard case.

[AkosLukacs]

Ran into the same thing (I guess)
First tried with a new project based on the current docs, but the simplest repro I could get is just dotnet run in tests\SqlProvider.Core.Tests\MsSql\ in this repo -> I get Hello Steven! after setting up the database and adjusting the connection string.
Change the version at line 42 to 1.1.40, and the build fails. I can go back and forth and build works or fails consistently.

After trying out other versions looks like v,1,1,37 works, 1.1.38 and up fails to build with the same error.

I'm on Win10, dotnet v.2.1.101.

[nikonthethird]

@AkosLukacs you might be on to something. I just tested with 1.1.37, it works. 1.1.38 doesn't.

I'd also like to point out that if you look at the commits, the last CI build before 1.1.38 works, but the CI build for 1.1.38 fails and it has been failing since.

I don't know if this is related at all and I can't quite make sense of the logs. but the timing would fit. Could this all be related to the changes to paket.lock?

[AkosLukacs]

Ookay, this is weird.
Just built the whole SQLProvider from latest source, and it built without any problem. All tests green too.
Referenced that dll in a dummy fsproj, adjusted the pre and postbuild steps to copy the dll from my built version, and it just works. Previously it was failing with 1.1.38+ nuget packages.
So maybe the issue is with the nuget package?

My code is here: https://github.com/AkosLukacs/SQLProvider529 Maybe it helps...
It contains "my" dll in the "lib" folder, that is built from the latest source.
Just comment / uncomment parts in the fsproj file to change PackageReference to local dll.

[Thorium]

We can revert the component upgrades if necessary but I hope the real cause behind this will be found.