Package testing skips Microsoft.Windows.Compatibility

[ericstj]

This is done because the package report doesn't list any supported frameworks.

That's because package reports only consider files and not dependencies. We should update the package reports to also consider dependencies (in the absence of files) to mirror the NuGet algo.

[ericstj]

As a result of this bug we missed this problem:

error NU1603: Microsoft.Windows.Compatibility 2.1.0-preview1-26928-03 depends on System.Data.SqlClient (>= 4.6.0-preview1-26928-03) but System.Data.SqlClient 4.6.0-preview1-26928-03 was not found. An approximate best match of System.Data.SqlClient 4.6.0-preview2-26905-02 was resolved.

Related: https://github.com/dotnet/corefx/issues/32391

[safern]

From the date of the package version it seems it is depending on a live version of the package. Was SqlClient package deleted or something?

[ericstj]

It was bumped to 4.7.0

[ericstj]

Let's see what we can do to make sure this gets tested. @joperezr we also may be missing updating the version of this in our index when a new one ships in servicing. I wonder if we need to expand the logic for index updates to account for dependencies in addition to harvesting.

[joperezr]

We could do that. If we make it so that every package (not only the ones that have dlls on them) has an entry on the package index, then we can call our task to update all stable versions listed in NuGet for all of the package index so that would cover these cases. Alternatively, we could also do what you suggest and expand the logic so that it also does it for dependencies.

[ViktorHofer]

Triage: keep this in 5.0 and at least manually test the meta-package.