Compilation error with .NET 6, SqlProgrammabilityProvider and WebSharper

[granicz]

(Reported by Clinton Düll - see original forum ticket at https://forums.websharper.com/topic/92665)

An F# .Net 6 library using SqlProgrammabilityProvider will fail to compile if the WebSharper.FSharp package is referenced. The following error arises: error FS3033: The type provider 'FSharp.Data.SqlProgrammabilityProvider' reported an error: Could not load file or assembly 'System.Data.SqlClient, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context. (0x80131058).

Steps to reproduce:

1. Create a new F# .Net 6 library in Visual Studio 2022 with FSharp.Core 6.0.5
2. Add the nuget package FSharp.Data.SqlClient 2.1.2
3. Add a reference to SqlProgrammabilityProvider - e.g. type S = SqlProgrammabilityProvider<""> (ignore the empty string compilation error, or add a valid connection string).
4. Add the nuget package WebSharper.FSharp 6.0.1.233
5. Compiling will now show the above error.

I'm reorganising a project and may not need this combination, but spent some time narrowing down the issue. The dependency of SqlProgrammabilityProvider on the .Net Framework at compile time may be of interest (https://fsprojects.github.io/FSharp.Data.SqlClient/netcore.html).

[granicz]

As a first check, I tried disabling the Booster by adding <WebSharperStandalone>True</WebSharperStandalone> to the project file. Same result. It seems this is an fsc.exe <-> wsfsc.exe issue. @Jand42 Let's take a deeper look.

[Jand42]

I'm looking at this, this must be something in fsc.exe vs Compile API in FSharp.Compiler.Services. Error happens during F# compilation via FCS, not in any WebSharper logic, so that at least narrows it down.

[cadull]

Following the trail of compilation issues with FSharp.Data.SqlClient, leads to recent activity by its developers to find a solution dotnet/fsharp#10323 (comment).
I'm working towards separating my usage of SqlProgrammabilityProvider and WebSharper into different libraries, which suits my particular project. Otherwise, I wonder if the workarounds that include a fsc.props file to manipulate the build tooling would work https://github.com/MarneeDear/FSharp.Data.SqlClient-dotnet/blob/master/fsc.props?

[Jand42]

@cadull @granicz Sorry for the late answer but there is no easy solution, except maybe going back to using WebSharper 4.x which has net4x compilation support.

WebSharper 5/6 runs the compiler on .NET 5/6, which includes doing the F# compilation too and there is no net4x fallback. So you won't gain anything by trying to force the F# compilation task to the net4x compiler, as WebSharper is skipping that anyways to do F#+JS compilations in single execution. An fsc.props trick could work to get a project using SQLProvider build via dotnet build but not with WebSharper for this reason.

Underlying cause is that SQLProvider TP is non-compliant on .NET Core-based compiler execution, they have multiple tickets around this... https://github.com/fsprojects/SQLProvider/issues?q=is%3Aissue+is%3Aopen+label%3A%22.NET+Core+reference+assembly+loading%22

So current workarounds are:

• Separating out SQLProvider TP use to a non-websharper compiled library (and add fsc.props trick if you need to build via dotnet build)
• WebSharper 4.x
• An alternative to SQLProvider e.g. https://github.com/cmeeren/Facil which uses code generation
• Fixing the issue in SQLProvider itself...

Re-adding net4x compilation path to WebSharper 6+ is not in the plans.