Dmitry Morozov

I agree - would be nice to have AsyncSeq as separate nuget package/project

Both Update and BulkCopy accept optional connection and/or transaction params.

I have no plans to roll-out Mono support myself. Too much effort because of in-comparability. But PRs are welcome.

I had this support before for SqlCommandProvider. It lead to ridiculously complex code like https://github.com/fsprojects/FSharp.Data.SqlClient/blob/f76e5068c13e87a56eebbc205f19afcc6398fb06/src/SqlClient/SqlClientExtensions.fs#L611 https://github.com/fsprojects/FSharp.Data.SqlClient/blob/f76e5068c13e87a56eebbc205f19afcc6398fb06/src/SqlClient/ISqlCommand.fs#L191 and other complications. Until Mono sql client implementation will follow some basic quality standards...

@xkrt Yes, there are plans to support .NET Core. But I'll wait until F# compiler will get decent on .NET Core. Speaking of Mono, if they will improve their System.Data.SqlClient...

This is not a trivial thing to do. But I promise to think about it.

The only solution as of today is to have actual database. Sql Express or LocalDB are not that bad to use for CI.

I was thinking about it. Maybe it's not a bad idea. What do you use at design time: connection string literal or config file?

Why don't you use Docker to host Sql Server instance accessible during compilation phase? It's so easy to do these days.

I think .NET 4.5 adoption is not wide enough to abandon ver 4.0 completely. I have exactly same thoughts about SqlDataReader.ReadAsync - overhead of one-row retrieval should be big enough...