Microsoft.Data.SqlClient

[Thorium]

I recommend first accepting my other PR and making that a minor version, then consider this.

This PR has Microsoft.Data.SqlClient and both .NET Framework and NET8.0 compatibility.

• Project builds (with some warnings).
• TestProjects do work and compile, with both with VS2022 and dotnet.exe
• Unit-tests: Test summary: total: 166, failed: 19, succeeded: 142, skipped: 5, duration: 7.5s.
  • So, not exactly everything is there, but it is very near. Some specific types have hiccup, I expect it's the Microsoft.SqlServer.Server.SqlDataRecord and these special SQL-server types
• Nuget-package: Does work, if you comment unit-tests, then you can e.g. build "2.2.0-alpha" if you want to test.

[smoothdeveloper]

@Thorium thanks, this looks very encouraging, I didn't had chance to try it out yet.

I tried to reach out to you on fsharp slack, in order to plan synchronous call if tractable on your end.

As it is, right now, I'll only merge either of two things, that we can definitely collaborate to bring to fruition:

• Full support for both ADO.NET drivers, by the mean of overloads
• Compile time conditionals, through which we would make two separate packages, we need to settle namespaces and package name

I'd favor the first one, which enables, over few releases, maybe 2 major releases, support, then obsoleted support, then removal of obsoleted support.

Otherwise we are going to break the ecosystem of users who use the library, it is not trivial to conduct a 100 switch over in large codebases, that have lots of historical, non encapsulated calls, even aside of using this library.

I want people doing .NET migration of this nonsense Microsoft has done, and using this library, to have a better experience switching over, and to me, supporting overloads makes the most sense, so the F# side of such migration is very easy, in comparison to .NET code that uses the raw ADO.NET APIs, which involve a lot of testing (talking about legacy applications with thousands of scattered ADO.NET API calls) for a switch over.

I hope the concern and intent I express is clear, and we can soon decide best way forward.

[Thorium]

I've been in a similar case before, and I recommend the following:

• Release a major version like version 3.0 (alpha if you want to test)
• Create a new branch for the current 2.1 maintenance. You can still use this branch to release whatever NuGet 2.x versions are needed for current users.
• If there are features needed for both, do them first for 2.x branch and then merge to 3.x branch, because the merges will be one-way.

This is exactly what they do with Microsoft.Data.SqlClient itself, e.g. their 5.2.1 is older than 5.1.7:

The whole System.Data.SqlClient package is tagged as obsolete, so this shouldn't bounce-back as major anymore, but it still receives security updates for current users. But it doesn't have e.g. MARS fixes, so it's unreliable under high load. I have to say I hate Microsoft.Data.SqlClient because of its massive dependency hierarchy, so I can imagine users who don't have any hurry to migrate (e.g. AWS users, because it has Azure dependencies).

[smoothdeveloper]

It is not because Microsoft is doing something stupid that I'll do the same. I'm fine with releasing a separate nuget package, with precompiler flags that keeps the same codebase.

I don't care about Microsoft dictating obsoleting, I care about legacy codebases, that are valuable to businesses everywhere, and not coercing maintainers of those into doing big bang refactoring, if they prefer a gradual update.

This is totally doable, we just need to collaborate and not get stuck with Microsoft dictating how big bang refactors get funded by their clients, on terms of Microsoft only.

[Thorium]

As far as I understand, FSharp.Data.SqlClient is an abstraction layer over the database driver, and both drivers (System.Data.SqlClient and Microsoft.Data.SqlClient) do support e.g. net462. So the user refactoring should be minimal (basically maybe catching some new Microsoft.Data.Exceptions if they now catch only System.Data.Exceptions).

The scary "platform not supported" error is not about platform at all, it's about picking libs-reference when runtime-reference should be used.

[smoothdeveloper]

This is why supporting both overload, for million $$$ codebases that are very legacy (not specific to FSharp.Data.SqlClient, but vanilla ADO.NET), those codebase will always face challenge in terms of claiming "Microsoft is forcing us to switch, like a big bang, from one release to next, from 0 to 100% switch" (because Microsoft doesn't, it enables gradual upgrade).

Instead, people need ability to change some of the calls, in some spots, and slowly build a momentum, that doesn't break product, or monopolize team for no value added to end users, beside adressing Microsoft diktat of deprecating package, but never be constrained to have one provider or other, exclusively, in the whole codebase.

This is why, I suggest my first solution, to support overloads, this is technically achievable, 100% backward compatible, and letting all freedom for consumers, to do their big bang thing in small codebase, or gradual thing in real world, legacy codebase (with so called "technical debt").

I agree this is changing namespace in code, seems trivial, but you discount that things needs to be tested, even for seemingly simple change, and it can be complex matter in many large codebases.

This is why I want people to be able to do gradual switch, even for FSharp.Data.SqlClient abstraction, I don't want the package to prevent users to do the gradual upgrade in a larger codebase.

In meantime, if people are in hurry, we can release a separate nuget, with a separate experimental branch or fork.