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

Use live dependencies for netcoreapp3.0 depencies (#48176) #48344

Merged
merged 5 commits into from
Mar 13, 2021

Conversation

ViktorHofer
Copy link
Member

Backport of d77092d.
Fixes #45560

Users are hitting an issue with needing to add an explicit reference to System.Text.Encodings.Web when they have System.Text.Json 5.0.0 in a netcoreapp3.1 project.

This is because the build of System.Text.Json for netcoreapp3.0 doesn't have a reference to the "live" built System.Text.Encoding.Web, instead it references the version from the shared framework. This creates a compatibility problem because the netstandard2.0 version references a higher version of the dependency than is inbox on netcoreapp3.0

Reported in dotnet/aspnetcore#28354 and dotnet/aspnetcore#28632. Documented in dotnet/AspNetCore.Docs#21054.

Customer Impact

Reported by customers who want to use the System.Text.Json 5.0.x package in a netcoreapp3.1 project and need to add an additional PackageReference to System.Text.Encodings.Web.

Regression?

Regressed between preview8 and rc1 of the 5.0.0 package.

Testing

Packages created locally and installed in a netcoreapp3.1 project. Transitive dependencies are coming along. NuSpec lists the dependencies.

Risk

Low/Medium. NuSpec and assembly metadata change.

@ghost
Copy link

ghost commented Feb 16, 2021

Tagging subscribers to this area: @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

Backport of d77092d.
Fixes #45560

Users are hitting an issue with needing to add an explicit reference to System.Text.Encodings.Web when they have System.Text.Json 5.0.0 in a netcoreapp3.1 project.

This is because the build of System.Text.Json for netcoreapp3.0 doesn't have a reference to the "live" built System.Text.Encoding.Web, instead it references the version from the shared framework. This creates a compatibility problem because the netstandard2.0 version references a higher version of the dependency than is inbox on netcoreapp3.0

Reported in dotnet/aspnetcore#28354 and dotnet/aspnetcore#28632. Documented in dotnet/AspNetCore.Docs#21054.

Customer Impact

Reported by customers who want to use the System.Text.Json 5.0.x package in a netcoreapp3.1 project and need to add an additional PackageReference to System.Text.Encodings.Web.

Regression?

Regressed between preview8 and rc1 of the 5.0.0 package.

Testing

Packages created locally and installed in a netcoreapp3.1 project. Transitive dependencies are coming along. NuSpec lists the dependencies.

Risk

Low/Medium. NuSpec and assembly metadata change.

Author: ViktorHofer
Assignees: ViktorHofer
Labels:

Servicing-consider, area-Infrastructure-libraries

Milestone: -

@ViktorHofer ViktorHofer requested review from ericstj and removed request for ahsonkhan, steveharter, layomia and jozkee February 16, 2021 16:54
@ericstj
Copy link
Member

ericstj commented Feb 16, 2021

Looks like the build breaks are due to Unsafe.As returning a nullable type:

public static T? As<T>(object? o) where T : class? { throw null; }

Odd that we don't hit this in master. Any idea why?

@ViktorHofer
Copy link
Member Author

Odd that we don't hit this in master. Any idea why?

No idea and absolutely confused about this. Unsafe's reference assembly uses nullable annotation for all configurations, so it can't be a tfm mismatch case between P2P and simple name reference.

@ericstj
Copy link
Member

ericstj commented Feb 17, 2021

Do we end up using the reference assembly in the same failing configuration, or is something else winning giving the compiler a different asset?

@ViktorHofer
Copy link
Member Author

Failure is #48469.

@leecow leecow added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Feb 18, 2021
@leecow leecow added this to the 5.0.5 milestone Feb 18, 2021
@ViktorHofer
Copy link
Member Author

@Anipik is the 5.0 branch already open?

@Anipik
Copy link
Contributor

Anipik commented Mar 1, 2021

@Anipik is the 5.0 branch already open?

not yet, i will take care of merging this when branch is open

@ViktorHofer
Copy link
Member Author

cool, thanks a lot. I think the package version and packageindex changes are also necessary before merging.

@Anipik
Copy link
Contributor

Anipik commented Mar 2, 2021

cool, thanks a lot. I think the package version and packageindex changes are also necessary before merging.

correct

@Anipik
Copy link
Contributor

Anipik commented Mar 11, 2021

@ViktorHofer any update on this one ?

@ViktorHofer
Copy link
Member Author

Yes on it right now

@ViktorHofer ViktorHofer force-pushed the NetCoreapp30DepsFixRel50 branch from c30edc8 to d50e45d Compare March 11, 2021 23:08
<PackageVersion>5.0.1</PackageVersion>
<AssemblyVersion Condition="$(TargetFramework.StartsWith('net4'))">5.0.0.1</AssemblyVersion>
<PackageVersion>5.0.2</PackageVersion>
<AssemblyVersion Condition="$(TargetFramework.StartsWith('net4'))">5.0.0.2</AssemblyVersion>
<SkipValidatePackage>true</SkipValidatePackage>
Copy link
Member Author

Choose a reason for hiding this comment

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

@Anipik is that setting intentional?

Copy link
Member Author

Choose a reason for hiding this comment

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

Found out that this is necessary when incrementing the assembly version for only a subset of supported TargetFrameworks. Unfortunately the servicing docs don't mention that.

@ViktorHofer
Copy link
Member Author

@Anipik the change is ready, please take a look.

@@ -928,11 +928,13 @@
"3.1.0",
"3.1.1",
"3.1.2",
"5.0.0"
"5.0.0",
"5.0.1"
Copy link
Member

Choose a reason for hiding this comment

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

Should you include baselineVersion here?

Copy link
Member

@ericstj ericstj left a comment

Choose a reason for hiding this comment

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

If Microsoft.Extensions.Logging.EventSource is referencing the latest Primitives on all frameworks and build succeeds, then this is safe to merge.

We should follow up by making sure all packages we build are baselined, otherwise our selective version bumps in servicing can result in some packages shipping references to GA packages even when the dependency is serviced. I suspect the Extensions packages never added baselines since they were added in 5.0 and used P2P but now that we're selectively versioning it matters.

@ViktorHofer ViktorHofer reopened this Mar 12, 2021
@ViktorHofer
Copy link
Member Author

/azp run runtime

@azure-pipelines
Copy link

Comment was made before the most recent commit for PR 48344 in repo dotnet/runtime

Copy link
Member

@ericstj ericstj left a comment

Choose a reason for hiding this comment

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

This looks like it addressed my concern. Thanks!

@ghost
Copy link

ghost commented Mar 12, 2021

Hello @ericstj!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@safern
Copy link
Member

safern commented Mar 12, 2021

Do we end up using the reference assembly in the same failing configuration, or is something else winning giving the compiler a different asset?

Could it be that in main we have an issue that for this case it is referencing the src project output? Unsafe is written in IL and only the ref assembly is nullable annotated.

@Anipik
Copy link
Contributor

Anipik commented Mar 12, 2021

cc @ViktorHofer @ericstj

C:\h\w\A0D708EB\p\packageTest.targets(82,5): error : Assembly 'System.Text.Json' has insufficient version for dependency 'System.Text.Encodings.Web' : 5.0.0.0 < 5.0.0.1. [C:\h\w\A0D708EB\w\BFB00A58\u\net5.0\project.csproj]
C:\h\w\A0D708EB\p\packageTest.targets(82,5): error : Assembly 'System.Text.Json' has insufficient version for dependency 'System.Text.Encodings.Web' : 5.0.0.0 < 5.0.0.1. [C:\h\w\A0D708EB\w\BFB00A58\u\net5.0\project.csproj]
  Testing System.Text.Json TFM=net5.0 RID=ubuntu.16.04-x64

@ericstj
Copy link
Member

ericstj commented Mar 12, 2021

So this appears to be happening because f27d337 updated the assembly version of S.T.E.W, and claims the updated version is part of .NET5.0 (which is not the case for GA). As a result we don't emit a PackageReference on .NET5.0 and the version referenced is unsatisfied.

@ericstj
Copy link
Member

ericstj commented Mar 12, 2021

We can't really undo this assembly-version bump now since it's been exposed. So I suggest we just correct the index. This will cause S.T.J to include the reference to S.T.E.W even on .NET5.0.

@ericstj
Copy link
Member

ericstj commented Mar 12, 2021

@Anipik -- please take note. That version change has made the ref-pack unserviceable. We would need to undo it for the net5.0 if we wanted to ship the ref-pack again from 5.0.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants