-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Conversation
src/libraries/shims/ApiCompatBaseline.netcoreapp.netstandard.txt
Outdated
Show resolved
Hide resolved
What about the references in runtime/src/libraries/pkg/descriptions.json Lines 550 to 568 in b8942c3
runtime/src/libraries/pkg/Microsoft.Private.PackageBaseline/packageIndex.json Lines 1416 to 1430 in b8942c3
runtime/src/mono/mono/metadata/assembly.c Line 163 in b8942c3
runtime/.config/CredScanSuppressions.json Lines 20 to 25 in b8942c3
etc.? |
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.
Fixed.
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.
Fixed. |
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.
If that lib does indeed need SqlClient, then we should also restore the old package to replace the live-built ref. |
src/libraries/restore/binplacePackages/binplacePackages.depproj
Outdated
Show resolved
Hide resolved
It's referenced but only one file imports the namespace and nothing from it is used. It's trivial to remove the dependency. |
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? |
All the code references in the tests seem to be from |
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? |
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? |
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:
|
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. |
We already restore test projects, why not just add a |
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! |
....Runtime.Serialization.Formatters/tests/System.Runtime.Serialization.Formatters.Tests.csproj
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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
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 For reference, here is the list of places where
|
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 👍 +💯 |
The test failures are known issues:
|
@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 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 Instead, it needs to pick up 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. |
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