Switch to `Microsoft.Data.SqlClient`

[daniellittledev]

Description

As Microsoft.Data.SqlClient is due to supersede/replace System.Data.SqlClient FSharp.Data.SqlClient should consider switching to Microsoft.Data.SqlClient.

[smoothdeveloper]

@daniellittledev thanks for creating this issue.

There is a comment regarding this: #337 (comment)

My current idea is that until the new client library provides for feature that would make it useful to consumers of the TP which can't be achieved with existing client, the disruption for existing consumers is going to be problematic.

I don't have experience switching codebase to new client library, and looking for feedback on this.

@daniellittledev have you started using Microsoft.Data.SqlClient?

[daniellittledev]

@smoothdeveloper my initial interest for this change is that Microsoft.Data.SqlClient appears to have better support for dotnetcore, in particular this was the issue that got me thinking about it #373. I'd love to start using it but you always have to wait for your dependencies to support it first.

It may be worth taking the same approach as Microsoft.Data.SqlClient and fork or branch off somehow and provide two packages, one for the old SqlClient and one for the new.

[smoothdeveloper]

@daniellittledev do you know if this can achieved while keeping the same codebase and using compiler defines rather than forking the library implementation?

[daniellittledev]

@smoothdeveloper I would assume so, but you would probably need two separate proj files as the dependencies would differ. They could both reference the same code and sit side by side.

I'm unsure if there is an better/easier way to do it.

[smoothdeveloper]

@daniellittledev you can have conditionals in the same fsproj as well for the reference.

[daniellittledev]

@smoothdeveloper ah great, of course!

[daniellittledev]

@smoothdeveloper I don't know much about how to implement type providers or how much time I have at the moment but I'm open to helping out if I can.

[smoothdeveloper]

@daniellittledev I'd be happy to help with this investigation effort but can't commit time authoring it right now.

I can help you get acquainted with the specificities related to TP, but those won't have significant interference with giving a try at changing the reference / changing the code.

If you are willing to take on this experiment, I'll be able to review, and help meet the gap to eventually allow shipping two versions based on a branch with a full port.

If you are looking to use the library with new client, I think you/someone giving it a try is a singificant enabling step.

[daniellittledev]

@smoothdeveloper ok, point me to anything you think would be helpful, I'll see what I can do.

[smoothdeveloper]

@daniellittledev you'll first need to add the references, in paket.dependencies DesignTime group and paket.references next to https://github.com/fsprojects/FSharp.Data.SqlClient/tree/master/src/SqlClient.DesignTime

also add the normal nuget package reference in https://github.com/fsprojects/FSharp.Data.SqlClient/blob/master/src/SqlClient/SqlClient.fsproj

after this, you can try replacing all the namespaces to point to new types, and get the solution to build, then the test projects green.

If this can be reached, we will ponder on how to keep dual target for the time being.

If you make a fork, you can open an experimental PR here to allow others to peek into the work.

[charlesroddie]

My current idea is that until the new client library provides for feature that would make it useful to consumers of the TP which can't be achieved with existing client, the disruption for existing consumers is going to be problematic.

UTF-8 support and the fact that there is a problem with System.Data.SqlClient (#373) are good enough reasons IMO.

[daniellittledev]

I've been looking a bit more at this, so a bit of an update

There are at least two dependencies that fail in a netstandard type provider:

System.Configuration.ConfigurationManager

This package is a Reference Assembly in netstandard and is only supported in net4x. Therefore it can not be used in a netstandard version.

Microsoft.SqlServer.Types

This package also only supports the net4x but it also has a dependency on System.Data.SqlClient which means no support in netstandard. The geospatial types it contains are also superseded by the NetTopologySuite package which EF Core now uses for dotnetcore support.

I'm still trying to get a working version, but I'll comment again when I do.

[smoothdeveloper]

@daniellittledev thanks a lot for the update.

So the two mentionned dependencies and features related to it may be put under conditional compilation.

I'm also thinking integrating the work for supporting 'Microsoft.Data.SqlClient' will be supported by an extra assembly / nuget package.

We will figure a way to support both from same codebase / solution, I think it is the best as it doesn't interfere with current consumers relying on the library and want to time their switch.

Going another way would likely deter usage of this library due to lots of incurred changes/disruption if we planned to just replace.

[daniellittledev]

@smoothdeveloper I agree minimising disruption is a good approach. Although I've decided to get it working first then see how we can merge the two.

I've also discovered Microsoft.Data.SqlClient depends on System.Configuration.ConfigurationManager as well so it can't be removed. Anyhow, I do have an idea of what to try next, there might be a way to force the inclusion of the implementation assemblies assuming there is one for netstandard.

p.s. There's no such thing as a netcore type provider is there (or is it just netcore and netfx)?