@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.

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).

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.

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.

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.

I'm giving a look at the issues, starting with UDTT handling, without usage of the type provider.

#r"nuget: Microsoft.SqlServer.Server"#r"nuget: Microsoft.Data.SqlClient"openMicrosoft.Data.SqlClientletconnectionString=@"Data Source=.;Initial Catalog=AdventureWorks2012;Integrated Security=True;TrustServerCertificate=true"douse cnx=new SqlConnection(connectionString)  cnx.Open()use cmd= cnx.CreateCommand()  cmd.CommandText<-"exec Person.myProc @x"letsqlMetas=[|      Microsoft.Data.SqlClient.Server.SqlMetaData("myId", System.Data.SqlDbType.Int)      Microsoft.Data.SqlClient.Server.SqlMetaData("myName", System.Data.SqlDbType.VarChar,30)|]letrecords=[|letr= Microsoft.Data.SqlClient.Server.SqlDataRecord(sqlMetas)      r.SetValues(1,"monkey")|> ignore      rletr= Microsoft.Data.SqlClient.Server.SqlDataRecord(sqlMetas)      r.SetValues(2,"donkey")|> ignore      r|]  cmd.Parameters.AddWithValue("@x", records|> Array.toSeq)|> ignoreuse reader= cmd.ExecuteReader()  ignore(reader.Read())letmyId= reader.GetInt32(0)letmyName= reader.GetString(1)  printfn"%d%s" myId myName

For now, in a script, under .net framework:

System.DllNotFoundException: Unable to load DLL 'Microsoft.Data.SqlClient.SNI.x64.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at Microsoft.Data.SqlClient.SNINativeManagedWrapperX64.UnmanagedIsTokenRestricted(IntPtr token, Boolean& isRestricted)
at Microsoft.Data.SqlClient.SNINativeMethodWrapper.UnmanagedIsTokenRestricted(IntPtr token, Boolean& isRestricted)
at Microsoft.Data.Win32NativeMethods.IsTokenRestrictedWrapper(IntPtr token)
at Microsoft.Data.ProviderBase.DbConnectionPoolIdentity.GetCurrentNative()
at Microsoft.Data.ProviderBase.DbConnectionPoolGroup.GetConnectionPool(DbConnectionFactory connectionFactory)
at Microsoft.Data.ProviderBase.DbConnectionFactory.GetConnectionPool(DbConnection owningObject, DbConnectionPoolGroup connectionPoolGroup)
at Microsoft.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection) at Microsoft.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource1 retry, DbConnectionOptions userOptions)
at Microsoft.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource1 retry) at Microsoft.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource1 retry, SqlConnectionOverrides overrides)
at Microsoft.Data.SqlClient.SqlConnection.Open(SqlConnectionOverrides overrides)
at <StartupCode$FSI_0004>.$FSI_0004.main@() in C:\dev\src\github\fsprojects\check.fsx:line 8
Stopped due to error

under dotnet 9:

System.ArgumentException: No mapping exists from object type Microsoft.FSharp.Collections.IEnumerator+mkSeq@177[[Microsoft.Data.SqlClient.Server.SqlDataRecord, Microsoft.Data.SqlClient, Version=6.0.0.0, Culture=neutral, PublicKeyToken=23ec7fc2d6eaa4a5]] to a known managed provider native type.
at Microsoft.Data.SqlClient.MetaType.GetMetaTypeFromValue(Type dataType, Object value, Boolean inferLen, Boolean streamAllowed)
at Microsoft.Data.SqlClient.MetaType.GetMetaTypeFromType(Type dataType)
at Microsoft.Data.SqlClient.SqlParameter.GetMetaTypeOnly()
at Microsoft.Data.SqlClient.SqlParameter.Validate(Int32 index, Boolean isCommandProc)
at Microsoft.Data.SqlClient.SqlCommand.BuildParamList(TdsParser parser, SqlParameterCollection parameters, Boolean includeReturnValue)
at Microsoft.Data.SqlClient.SqlCommand.BuildExecuteSql(CommandBehavior behavior, String commandText, SqlParameterCollection parameters, _SqlRPC& rpc)
at Microsoft.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean isAsync, Int32 timeout, Task& task, Boolean asyncWrite, Boolean inRetry, SqlDataReader ds, Boolean describeParameterEncryptionRequest)
at Microsoft.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry, String method)
at Microsoft.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at Microsoft.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
at Microsoft.Data.SqlClient.SqlCommand.ExecuteReader()
at <StartupCode$FSI_0002>.$FSI_0002.main@() in C:\dev\src\github\fsprojects\check.fsx:line 25
at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
Stopped due to error

For the runtime you need the best possible performance, so you want the SNI to be near. Luckily the proper runtime selection of Microsoft.Data.SqlClient.SNI.x64.dll will be handled by .NET runtime.

However, for the compile-time and design-time, you don't know well the proper SNI but you still need to execute SQL. But in the design-time the milliseconds doesn't matter so much. That's why theDesignTime.fs hasAppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.UseManagedNetworkingOnWindows", true); // No Windows SNI in design-time

In that sense, if you want to use Windows SNI directly from FSI then I think you need to add
#r "nuget: Microsoft.Data.SqlClient.SNI.runtime"