Description
In 2.1.26, we found that, despite CoreFx shipping a new version of System.Text.Encodings.Web
, we failed to include the new version of the binary in Microsoft.Aspnetcore.App``. The reason for this is that the we didn't patch any of the 3 projects that depend on S.T.E.W, so all references to it were resolved as BaselinePackageReferences
, which still point to the unpatched version. I found this by examining the binlog and noticing that, despite `SystemTextEncodingsWebPackageVersion` being updated to 4.5.0, all of the resolved `PackageReferences` to it had version 4.5.0, and were coming from our `ResolveCustomReferences` target. We should fix our logic so that the SharedFx always gets the latest version of any assembly coming from repos below us.
Strangely, this behavior was not present for at least one recent ingestion of a patched CoreFx library. System.IO.Pipelines
was patched in the 2.1.23 build, and we did not ship any patched packages, but Microsoft.AspNetCore.App did include the latest version of System.IO.Pipelines. I haven't figured out why it worked then but not now.
Original text from email:
My working theory is that we’re actually resolving this dependency from our package baseline, where its version is [4.5.0, ]. The only projects we have that reference S.T.E.W all have it listed as BaselinePackageReferences in our baseline, so they all resolve it from there, and get the 4.5.0 version – nothing is restoring it as an external reference with the 4.5.1 version, So it’s the 4.5.0 version that actually gets restored. See these 3 projects which are the only ones that reference S.T.E.W:
And their baseline entries, which list a BaselinePackageReference to S.T.E.W at 4.5.0 or higher:
aspnetcore/eng/Baseline.Designer.props
Lines 422 to 423 in a401d81
aspnetcore/eng/Baseline.Designer.props
Lines 429 to 431 in a401d81
aspnetcore/eng/Baseline.Designer.props
Lines 1162 to 1164 in a401d81