System.Data.SqlClient packaging

[jkotas]

From dotnet/corefx#25134 (comment):

And for better or worse, we already have some such dependencies, e.g. System.Data.SqlClient isn't part of the .NET Runtime download but it does P/Invoke into the System.Net.Security.Native.so/dylib shim.

We either need to fix that, or we need to add a test coverage to ensure that you can mix and match different versions of .NET Core Runtime (that bundles System.Net.Security.Native.so/dylib) with different versions of System.Data.SqlClient and document/enforce the supported mixing and matching.

The packaging for System.Data.SqlClient is suspect in general: All build configurations in https://github.com/dotnet/corefx/blob/master/src/System.Data.SqlClient/src/Configurations.props are netstandard. How am I going to get the .NET Core shims that the implementation depends on when I install it on Mono?

[divega]

@jkotas as you probably know, future development of SqlClient will happen on a new package, Microsoft.Data.SqlClient, that will be hosted in https://github.com/dotnet/SqlClient. System.Data.SqlClient will still be built in CoreFx, be supported and receive fixes for high priority bugs.

Are the concerns described by this issue are still current? Could you elaborate on how they map to both System.Data.SqlClient and Microsoft.Data.SqlClient?

I am trying to make sure that this is in terms that it can be actionable for the SqlClient team, and that we track the issue in the right place (e.g. CoreFx, SqlClient, or both).

[jkotas]

Yes, the issues are still current for both Microsoft.Data.SqlClient and System.Data.SqlClient packages.

For Microsoft.Data.SqlClient package, you should delete all files from the implementation that P/Invoke into the System.*.Native.so/dylib shims. I do see these P/Invokes in the current preview versions of https://www.nuget.org/packages/Microsoft.Data.SqlClient/. These shims are internal implementation detail in CoreFX and they are not guaranteed to be stable. If you need them, you should have your own that you have a control over and that you ship as part of the package.

For System.Data.SqlClient package, I understand that you may prefer to not fix this since the package is in the sustained engineering mode. If you do not fix it, you are running a risk that System.Data.SqlClient package will break on new runtimes. However, once/if that happens - we will hopefully be able to tell people to switch to Microsoft.Data.SqlClient or fix it at that time.

[davidsh]

We discussed this in an offline email thread. The new plan is that we will fix System.Net.Security.Native.* shims so that they remain compatible across either .NET Core 2.x or .NET Core 3.x runtimes. So, System.Data.SqlClient and Microsoft.Data.SqlClient can keep the existing dependency.

Long term (.NET 5), we plan to address this in dotnet/corefx#36896 with a public API in .NET Core that will expose Kerberos APIs that can be consumed instead of depending on these internal .NET Core native shims.