Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delete System.Data.SqlClient package #2275

Merged
merged 7 commits into from
Feb 5, 2020
Merged

Delete System.Data.SqlClient package #2275

merged 7 commits into from
Feb 5, 2020

Conversation

jkotas
Copy link
Member

@jkotas jkotas commented Jan 28, 2020

This package is superseded by Microsoft.Data.SqlClient that lives in https://github.com/dotnet/SqlClient repo.

Fixes https://github.com/dotnet/corefx/issues/40846

@stephentoub
Copy link
Member

stephentoub commented Jan 28, 2020

What about the references in

"Name": "System.Data.SqlClient",
"Description": "Provides the data provider for SQL Server. These classes provide access to versions of SQL Server and encapsulate database-specific protocols, including tabular data stream (TDS)",
"CommonTypes": [
"System.Data.SqlClient.SqlConnection",
"System.Data.SqlClient.SqlException",
"System.Data.SqlClient.SqlParameter",
"System.Data.SqlDbType",
"System.Data.SqlClient.SqlDataReader",
"System.Data.SqlClient.SqlCommand",
"System.Data.SqlClient.SqlTransaction",
"System.Data.SqlClient.SqlParameterCollection",
"System.Data.SqlClient.SqlClientFactory"
]
},
{
"Name": "System.Data.SqlClient.sni",
"Description": "Internal implementation package not meant for direct consumption. Please do not reference directly. Provides native implementation dll used by System.Data.SqlClient.",
"CommonTypes": []
},

"System.Data.SqlClient": {
"StableVersions": [
"4.1.0",
"4.3.0",
"4.3.1",
"4.4.0",
"4.4.1",
"4.4.2",
"4.4.3",
"4.5.0",
"4.5.1",
"4.6.0",
"4.6.1",
"4.7.0"
],

-nonamespace System.Data.SqlClient.Tests

FACADE_ASSEMBLY ("System.Data.SqlClient"),

"/src/libraries/System.Data.SqlClient/src/System/Data/SqlClient/TdsEnums.cs",
"/src/libraries/System.Data.SqlClient/tests/FunctionalTests/DiagnosticTest.cs",
"/src/libraries/System.Data.SqlClient/tests/FunctionalTests/ExceptionTest.cs",
"/src/libraries/System.Data.SqlClient/tests/FunctionalTests/SqlConnectionBasicTests.cs",
"/src/libraries/System.Data.SqlClient/tests/Tools/TDS/TDS.Servers/TDSServerArguments.cs",
"/src/libraries/System.Data.SqlClient/tests/Tools/TDS/TDS.Servers/TdsServerCertificate.pfx",

etc.?

@jkotas
Copy link
Member Author

jkotas commented Jan 28, 2020

"Name": "System.Data.SqlClient",
"Description": "Provides the data provider for SQL Server. These classes provide access to versions of SQL Server and encapsulate database-specific protocols, including tabular data stream (TDS)",
"CommonTypes": [
"System.Data.SqlClient.SqlConnection",
"System.Data.SqlClient.SqlException",
"System.Data.SqlClient.SqlParameter",
"System.Data.SqlDbType",
"System.Data.SqlClient.SqlDataReader",
"System.Data.SqlClient.SqlCommand",
"System.Data.SqlClient.SqlTransaction",
"System.Data.SqlClient.SqlParameterCollection",
"System.Data.SqlClient.SqlClientFactory"
]
},
{
"Name": "System.Data.SqlClient.sni",
"Description": "Internal implementation package not meant for direct consumption. Please do not reference directly. Provides native implementation dll used by System.Data.SqlClient.",
"CommonTypes": []
},

"System.Data.SqlClient": {
"StableVersions": [
"4.1.0",
"4.3.0",
"4.3.1",
"4.4.0",
"4.4.1",
"4.4.2",
"4.4.3",
"4.5.0",
"4.5.1",
"4.6.0",
"4.6.1",
"4.7.0"
],

These lists have references to all packages that were ever built in CoreFX, even many dead ones. I have kept it that way for consistency. @ericstj Let me know if SqlClient should be cleaned up from these lists.

-nonamespace System.Data.SqlClient.Tests

Fixed.

FACADE_ASSEMBLY ("System.Data.SqlClient"),

This list is for legacy Mono. Nothing is changing for legacy Mono with this change. These sources live in dotnet/runtime as side-effect of bulk source sharing with legacy Mono.

"/src/libraries/System.Data.SqlClient/src/System/Data/SqlClient/TdsEnums.cs",
"/src/libraries/System.Data.SqlClient/tests/FunctionalTests/DiagnosticTest.cs",
"/src/libraries/System.Data.SqlClient/tests/FunctionalTests/ExceptionTest.cs",
"/src/libraries/System.Data.SqlClient/tests/FunctionalTests/SqlConnectionBasicTests.cs",
"/src/libraries/System.Data.SqlClient/tests/Tools/TDS/TDS.Servers/TDSServerArguments.cs",
"/src/libraries/System.Data.SqlClient/tests/Tools/TDS/TDS.Servers/TdsServerCertificate.pfx",

Fixed.

@ericstj
Copy link
Member

ericstj commented Jan 28, 2020

packageIndex.json

The PackageIndex.json shouldn't be changed. We need this in order to emit the right package dependencies for libraries which depend on SqlClient. It looks like OleDb still depends on SqlClient.

<Reference Include="System.Data.SqlClient" />

If that lib does indeed need SqlClient, then we should also restore the old package to replace the live-built ref.

@Wraith2
Copy link
Contributor

Wraith2 commented Jan 28, 2020

If that lib does indeed need SqlClient, then we should also restore the old package to replace the live-built ref.

It's referenced but only one file imports the namespace and nothing from it is used. It's trivial to remove the dependency.

@ericstj
Copy link
Member

ericstj commented Jan 28, 2020

Much better to remove it completely if it isn’t needed.

We will still need something like the restore step to get the System.Data shim correct.

@jkotas
Copy link
Member Author

jkotas commented Jan 28, 2020

Much better to remove it completely if it isn’t needed.
We will still need something like the restore step to get the System.Data shim correct.

I have done both these. Thanks!

The last problem that I have is how to drop System.Data.SqlClient.dll into the testhost. System.Data.Common tests depend on it. What is the best way to drop System.Data.SqlClient.dll into the testhost?

@Wraith2
Copy link
Contributor

Wraith2 commented Jan 30, 2020

All the code references in the tests seem to be from DbProviderFactoriesTests and could be replaced with another provider as far as I can see.

@ViktorHofer
Copy link
Member

Doesn't binplacing System.Data.SqlClient from a package into the runtime/testhost directory mean that during sourcebuild we need that package as a pre-built?

@Wraith2
Copy link
Contributor

Wraith2 commented Feb 3, 2020

If you only need the sqlclient library for the System.Data tests you could just replace the provider tests with OleDB or ODBC as the provider and then you don't need sqlclient or it's tests for this build do you?

@jkotas
Copy link
Member Author

jkotas commented Feb 3, 2020

I need System.Data.SqlClient references for the source build, and I would like to keep it for running tests as well (e.g. the new test that I am adding in this PR). I do not think it should be a problem for source build:

  • References are handled via ilasm from .il for source build
  • Tests are not a problem for source build.

@ericstj
Copy link
Member

ericstj commented Feb 4, 2020

Doesn't binplacing System.Data.SqlClient from a package into the runtime/testhost directory mean that during sourcebuild we need that package as a pre-built?

Depends on what part of the build needs it. Today, we already have a prebuilt requirement for shims which is the only part of the product build that requires this. We do a two-pass build, where first pass can consume the reference, second pass can use the generated source. I think we can piggy-back on that.

Tests are already are allowed to have prebuilts in source build.

@safern
Copy link
Member

safern commented Feb 5, 2020

The last problem that I have is how to drop System.Data.SqlClient.dll into the testhost.

We already restore test projects, why not just add a PackageReference in the test project to the given package?

@jkotas
Copy link
Member Author

jkotas commented Feb 5, 2020

why not just add a PackageReference in the test project to the given package?

This is what I have done - the last two commits are the change required to flip from including it in the runtime to making the PackageReference work). It is hitting a bug in Mono assembly loader. I have disabled the affected test and will file an issue on it if the rest looks good.

This is passing the CI now. The change should be ready to review!

Copy link
Member

@ViktorHofer ViktorHofer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM. I would like to know why we need to copy into the runtime/testhost before merging though.

- Add System.Data.SqlClient package references for tests that need it
- Use System.Data.SqlClient reference assembly to build the System.Data shim
- Disable ILLinker for the shims since it does not work well with incremental builds and it is not necessary anyway

Try to use package references in tests
@jkotas
Copy link
Member Author

jkotas commented Feb 5, 2020

why we need to copy into the runtime/testhost before merging though.

We do not copy it in my latest version of the change. I have switched the tests that need it to have local package references and removed copying of System.Data.SqlClient.dll into runtime/testhost.

For reference, here is the list of places where System.Data.SqlClient.dll is placed under artifacts\bin after running build.cmd. All of them are refs.

\runtime\artifacts\bin\binplacePackages\netcoreapp5.0-Release\System.Data.SqlClient.dll
\runtime\artifacts\bin\binplacePackages\netstandard2.0-Release\System.Data.SqlClient.dll
\runtime\artifacts\bin\netstandard\netstandard2.0-Release\System.Data.SqlClient.dll
\runtime\artifacts\bin\ref\netcoreapp5.0\System.Data.SqlClient.dll
\runtime\artifacts\bin\ref\netstandard2.0\System.Data.SqlClient.dll

@ViktorHofer
Copy link
Member

ViktorHofer commented Feb 5, 2020

Thanks, I thought I still saw the PackageReference in runtime.depproj but maybe that was an old commit. Thanks for not writing into the runtime/testhost folder 👍 +💯

@jkotas
Copy link
Member Author

jkotas commented Feb 5, 2020

The test failures are known issues:

  • Failed to acquire dotnet install script
  • Docker container recycling problem

@jkotas jkotas merged commit 722cf30 into dotnet:master Feb 5, 2020
@safern
Copy link
Member

safern commented Feb 6, 2020

@jkotas it seems like this broke the rolling build tests on Linux_musl_arm64 (Alpine).

Binary formatter tests are failing: https://helix.dot.net/api/2019-06-17/jobs/ed130407-35ad-40cc-a9ef-24b9767b2a77/workitems/System.Runtime.Serialization.Formatters.Tests/console

The Binary Data that is failing seems to be System.Data objects. L581 of https://github.com/dotnet/runtime/blob/master/src/libraries/System.Runtime.Serialization.Formatters/tests/BinaryFormatterTestData.cs#L581 (GH won't show it since it is too big).

Also, System.Data.Common: https://helix.dot.net/api/2019-06-17/jobs/cb568d05-e0c9-4b5d-a292-1ac6dd5847a9/workitems/System.Data.Common.Tests/console

https://dev.azure.com/dnceng/public/_build/results?buildId=509595&view=ms.vss-test-web.build-test-results-tab

It could be related to the asset in the package reference having a bug or not picking the right one for Linux_musl_arm64 but not sure.

@jkotas
Copy link
Member Author

jkotas commented Feb 6, 2020

It could be related to the asset in the package reference having a bug or not picking the right one for Linux_musl_arm64 but not sure.

Right, the problem is that the build for musl picks up lib\netcoreapp2.1\System.Data.SqlClient.dll from the https://www.nuget.org/packages/System.Data.SqlClient/ . This .dll is a stub implementation that throws PlatformNotSupportedExceptions in most methods.

Instead, it needs to pick up runtimes\unix\lib\netcoreapp2.1\System.Data.SqlClient.dll .

I have verified that a simple console app published for must gets the right one. So this has to do with some customization of package restore that we got in the build. Do you happen to know where that may happen?

A simple way to fix this is to switch back to copying System.Data.SqlClient.dll to testhost. I will do that.

@jkotas
Copy link
Member Author

jkotas commented Feb 6, 2020

#31850

@jkotas jkotas deleted the sqlclient branch February 7, 2020 20:02
@ghost ghost locked as resolved and limited conversation to collaborators Dec 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants