Dapper: Support for Microsoft.Data.SqlClient

[AdaskoTheBeAsT]

Microsoft just released news about .NET 5 and new lib Microsoft.Data.SqlClient which will eventually replace SqlClient in System.Data. Probably bit too early but I am interested how that new lib can be used by dapper?

[mgravell]

Ah, finally I can stop worrying about leaking that info! Since Dapper "core" mostly just wraps the connection, in not cases it should just work. I need to check for any subtleties in things like TVPs, but my expectation is that this will be trivial. Obviously I couldn't spike it in a public branch until it wasn't a secret.

The side libs like Rainbow etc may need to be educated about a new fully qualified name, but again: I expect this to be trivial. It should mostly work OOTB.

[NickCraver]

I agree the code/function side is useful...the problem I foresee is the dependency, eventually (as it stands) would bring in the old library instead of the new. The dependency I think we still need to figure out...right?

[mgravell]

Tracking code: https://github.com/StackExchange/Dapper/pull/1262

[mgravell]

@NickCraver actually we only need the dependency for one API:

``` c#
public static ICustomQueryParameter AsTableValuedParameter(
this IEnumerable list,
string typeName = null)

There is one other dependency specific to netstandard1.3, but we can work around that (or just drop 1.3? #toosoon?)

However! `SqlDataRecord` is specifically one of the broken "defined in two assemblies, oops" errors, so um... yeah.

I've added a generic solution in the hope that it'll work (when the above is resolved):

``` c#
public static ICustomQueryParameter AsTableValuedParameter<T>(
    this IEnumerable<T> list,
    string typeName = null) where T : IDataRecord

We could drop the old API in a major, at which point we can drop the System.Data.SqlClient dependency.

[NickCraver]

Maybe a separate Dapper.SqlServer? But then which dependency do you pick...you're likely to be crossing the streams between both libraries for a large number of apps either way. Oy.

I'm not worried about dropping the dependency overall, since we can easily tell people to just add a <PackageReference/> if they need - but how best to separate those extensions is more of a question...do we pick newer? or have 2 libs? or...?

[iguanaware]

Microsoft just released news about .NET 5 and new lib Microsoft.Data.SqlClient which will eventually replace SqlClient in System.Data. Probably bit too early but I am interested how that new lib can be used by dapper?

I'm seeing it in core 3 preview 6. So this is going to be a problem in a short couple of months.

[mgravell]

I have done the initial work on this; I'm currently blocked by the SqlDataRecord problem (although I learned a new trick this week: how to get extern-alias working with nuget, so I might be able to get past that...). But: just assume that we've got this covered :)

[yyjdelete]

Note the type SqlDataRecord now moved from Microsoft.SqlServer.Server.SqlDataRecord to Microsoft.Data.SqlClient.Server.SqlDataRecord for Microsoft.Data.SqlClient >= 1.0.19189.1-Preview

[Poolitzer80]

Any news on this?

[mgravell]

Any news on this?

Dapper 2.* (presumably just pick "latest") should just work with either SqlClient library. If you're seeing some problems, please be specific, but again: probably "done". Closing on that basis, but happy to reopen if there's a gap.