Add IDBColumnSchemaGenerator interface to netfx SqlDataReader

[MichelZ]

Bring IDBColumnSchemaGenerator to netfx for later code base merging

I made sure to enable the respective test for netfx

Part of #2965

[MichelZ]

/azp run

[azure-pipelines]

Commenter does not have sufficient privileges for PR 2967 in repo dotnet/SqlClient

[MichelZ]

@edwardneal Would you mind running the pipeline for me on this one? :)

[edwardneal]

Thanks for this MichelZ. The changes look good to me; would you mind feeding the extra package reference through to the nuspec file and the .NET Framework reference csproj please?

I don't have access to the pipelines, but hopefully the SqlClient team will be able to look at it in a few days. Something's definitely odd there - your PRs didn't run the CI builds, and my commit ran the CI build but encountered a lot more timeouts than normal in the tests.

[MichelZ]

Will do. I'm not a contributor, that's probably why the pipelines don't run for me (yet)
(Can you try to just do an /azp run and see what happens?)

[MichelZ]

Not 100% sure about this one. Was the intention here to exclude schemaTable for netcore?

[benrr101]

Yeah, this kind of code doesn't make a ton of sense to me (the original, that is). It'd be nice if it came with a comment that explains what's the rationale for whats going on but ... whatever.

As for your change, I'm also not 100% about it either. It basically says we assign the dbColumnSchema in netcore, and assign the schemaTable in netfx. So, I wonder if assigning both in both cases is the right behavior...

[edwardneal]

/azp run

[azure-pipelines]

Commenter does not have sufficient privileges for PR 2967 in repo dotnet/SqlClient

[MichelZ]

Thanks for trying :)

[ErikEJ]

/azp run

[azure-pipelines]

Commenter does not have sufficient privileges for PR 2967 in repo dotnet/SqlClient

[benrr101]

@ErikEJ @edwardneal @MichelZ We have changed security rules recently such that only contributors can kick off pipeline runs. This is due to the potential for contributors to run code in PRs that could be hazardous to our build agents or cause a DoS.

[benrr101]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[MichelZ]

This package needs to be added to the sqlclientdriver nuget feed for this build to succeed:
System.Data.Common: 4.3.0

[benrr101]

@MichelZ I might've mentioned it before but yep, we've got security on the internal nuget feed such that only contributors can pull upstream packages from the feed. I've gone ahead and added System.Data.Common 4.3.0 to the feed, so it should be good to go.

[benrr101]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[benrr101]

I'd need to see @cheenamalhotra 's opinion regarding the System.Data.Common inclusion before I explicitly approve.

[benrr101]

Yeah, this kind of code doesn't make a ton of sense to me (the original, that is). It'd be nice if it came with a comment that explains what's the rationale for whats going on but ... whatever.

As for your change, I'm also not 100% about it either. It basically says we assign the dbColumnSchema in netcore, and assign the schemaTable in netfx. So, I wonder if assigning both in both cases is the right behavior...

[benrr101]

Is this package not compatible with netcore? I know a lot of packages are still compatible with netcore but just don't do anything in scenarios where they're not needed (eg, System.Memory being part of the netcore).

[MichelZ]

It's a netstandard1.2 package, there are no explicit .NET Core versions of it, so I thought better not mess with the .NET Core side

[benrr101]

I'm kinda confused about this one - it seems like we've needed to build against System.Data.Common for a long time. So I'm concerned why we're only just now adding it. @cheenamalhotra do you know the history behind how we relate to System.Data.Common?

[edwardneal]

It looks like System.Data.Common is packaged in-box with .NET Framework 4.7.1 and upwards, but since we're targeting .NET Framework 4.6.2 we need the package reference. .NET Core doesn't have this problem - all the versions we target package it in-box.