.NET Standard 2.0 support

[Thorium]

This branch is released as a test version 1.1.12-alpha5 in the NuGet.org.

Current possible issues:

• The release process has now a manual step, I don't know what generates "Unsupported0.0": Rename SQLProvider.*.nupkg to zip, open SQLProvider.nuspec inside it and replace "Unsupported0.0" to ".NETStandard2.0", update the file to zip-package, then rename it back and upload from NuGet.org or command-line.
• I have not tested build on Linux/Mac or Mono.
• Build package contains a few .NET 4.6.1 files. I don't know if this is a problem as .NET 4.6.1 is said to be .NET Standard 2.0.0 compatible.

More info: http://fsprojects.github.io/SQLProvider/core/netstandard.html

This contains #451 . Ping #426 #303 : We need more testing.

[piaste]

Hmm. This build gives me a StackOverflowException in fcs.exe. Tested with the fcs.exe from the latest nightly (2017.8.9.1) and the one from the latest nuget FSharp.Compiler.Services (4.1.23).

Repro:

dotnet new console -lang f#
dotnet add package SqlProvider -v 1.1.12-alpha-5
dotnet add package Npgsql
dotnet restore
add open FSharp.Data.Sql to Program.fs

At this point there is a red squiggle under 'Sql', so I looked at the example and added a PropertyGroup for FscToolPath and FscToolExe to the project file. This fixes the squiggle (should probably add this to the documentation).

Then, dotnet build -v detailed leads to:

 Microsoft (R) F# Compiler version 4.1
         Copyright (c) Microsoft Corporation. All Rights Reserved.

         Process is terminating due to StackOverflowException.

(etc..)

 "D:\MyProjects\sqldotnet\sqldotnet.fsproj" (Build target) (1) ->
       (CoreCompile target) ->
         C:\Program Files\dotnet\sdk\2.0.0\FSharp\Microsoft.FSharp.Targets(224,9): error MSB6006: "RunFsc.cmd" exited with code -1073741571. [D:\MyProjects\sqldotnet\sqldotnet.fsproj]

    0 Warning(s)
    1 Error(s)

Any tip for how I can diagnose this further?

Just for confirmation, commenting out the PackageReference (but leaving the FcsTool property) builds successfully.

[Thorium]

What environment you are on, Win, Mac or Ubuntu?
If you take a clean copy of SQLProvider's netstandard-branch, then run .\.paket\paket.bootstrapper.exe and .\.paket\Paket.exe restore
and go to tests\SqlProvider.Core.Tests and run dotnet add package Npgsql and then dotnet restore and dotnet build will it work?

I have read something about a StackOverflowException bug in fcs.exe when compiling .net core, but don't know a lot about it.

[piaste]

What environment you are on, Win, Mac or Ubuntu?

Win10 x64, .NET Core 2.0, .NET Framework 4.7.

If you take a clean copy of SQLProvider's netstandard-branch, then run ..paket\paket.bootstrapper.exe and ..paket\Paket.exe restore
and go to tests\SqlProvider.Core.Tests and run dotnet add package Npgsql and then dotnet restore and dotnet build will it work?

No, same StackOverflowException.

I have read something about a StackOverflowException bug in fcs.exe when compiling .net core, but don't know a lot about it.

Possible. I can compile other f# .NET Core projects though, so if that's the bug it isn't total.

[piaste]

dotnet/fsharp@34e669c

StackOverflowException bug may have been fixed a few minutes ago, and it seems it was specific to TP assembly loading.

As soon as I can install a fresh CI build, I'll check if it solved my problem.

[Thorium]

Now there is example at https://github.com/fsprojects/SQLProvider/tree/netstandard/tests/SqlProvider.Core.Tests/Postgres

Hmm. I don't know if we should modify the dynamic reference loading, as database connection libraries seem to have more and more references. Currently we look just from the resolution folder, but what if there are multiple files to load from different NuGet packages, and loading one dll with Assembly.LoadFrom needs sub-dlls from dependency assemblies? Latest MySQL.Data is having a lot of them: https://www.nuget.org/packages/MySql.Data/8.0.9-dmr

[Thorium]

Tested the old 4.5.1 version thoroughly, won't break anything, so ok to merge.

[Thorium]

Ping @piaste can you try the latest version? No matter what F# compiler version, I think I got the issue solved by using a different assembly loading technique.

[piaste]

Cloning the netstandard branch and attempting to build Sqlprovider.Core.Tests\Postgres doesn't give a SOE any more. :)

Fsc.exe still errors out from being unable to reference System.Threading.Tasks.Extensions.dll and System.Data.Common. I haven't figured out in which folder I should copy them in order to make the project compile. With the old .NET Framework I just copied them in the project's root, doesn't seem to work here.

     1>D:\MyProjects\sqlclean\Sqlprovider\tests\SqlProvider.Core.Tests\Postgres\Program.fs(20,11): error FS3033: The type provider 'FSharp.Data.Sql.SqlTypeProvider' reported an error: Unab
le to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.�Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.1.0
.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.�Could not load file or assembly 'System.Data.Common, Version=0.0
.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. [D:\MyProjects\sqlclean\Sqlprovider\tests\SqlProvider.Core.Te
sts\Postgres\SqlProvider.Core.Tests.fsproj]

Just in case, the 1.1.12-alpha-8 version on nuget still has the stack overflow error (and I installed the latest nightly too).

[Thorium]

Npgsql.dll is depending on System.Threading.Tasks.Extensions.dll and System.Data.Common.dll so they have to be present. In the example I have a PreBuildEvent (in the bottom of fsproj-file) that copies the two files from their NuGet packages to ResolutionPath (temp) that is given as a static parameter to SqlDataProvider type constructor.

Edit: Also run Paket restores described above before build to get the dlls. The tests\SqlProvider.Core.Tests\Postgres is actually using 1.1.12-alpha-8 and not the latest binary. The reason is that binary references don't seem to work properly on net core.

[tforkmann]

Hi @Thorium, I implemented the dotnet feature as well, but I also get the StackOverflowException.

I tried to add the preBuild parameters but that didn't help.

I have the following setup:

Win10 x64, .NET Core 2.0, .NET Framework 4.7. MS SQL Server 2008

nuget SqlProvider 1.1.12-alpha8

My fsproj file looks like that:

Any ideas how to solve my issue?

[Thorium]

@tforkmann I assume you are using MsSql. Can you get the example to work:
https://github.com/fsprojects/SQLProvider/tree/netstandard/tests/SqlProvider.Core.Tests/MsSql

[tforkmann]

It's working.

I guess I'm missing a package.

Thanks for now.

[Thorium]

@piaste discovery of dlls is improved in the latest alpha. But copying those to ref-path is still needed. The default .Net Core way to discovery reference assemblies from Nuget packages when loading dlls with reflection is not working very well with compiler plugins like Type Providers.

[Thorium]

MySQL Core example is pending a solution for this: https://bugs.mysql.com/bug.php?id=88016
Maybe I should compile a custom version on MySql.Data.dll but I hope I don't have to.

Edit: ...and GetSchema() is not supported by .NET Core version of MySql.Data.dll so fixing the security levels is not enough anyways.

[piaste]

Update: the current netstandard branch works on Postgres without any copying at all :) Thanks @Thorium

[Thorium]

Great!
Now we should have working sample test projects for .NET CoreApp 2 for:

• Microsoft SQL Server
• MYSQL
• Postgres
• SQLite

That should cover most of testing and production cases for .NET Core.
This branch will be merged soon.