Skip to content

Conversation

@Anipik
Copy link
Contributor

@Anipik Anipik commented Aug 17, 2020

  • update the package versions
  • update the assembly and product verision
  • fix the package baseline file using the repoupdatePackageBaseline target
  • fix the paths.

@ghost
Copy link

ghost commented Aug 17, 2020

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

@ericstj
Copy link
Member

ericstj commented Aug 17, 2020

Can you double check every project that

  1. Has a pkgproj
  2. Has a $(NetCoreAppCurrent) target framework
  3. Does not set ExcludeCurrentNetCoreAppFromPackage = true

And add a net5.0(-*) TargetFramework as appropriate?

Copy link
Member

Choose a reason for hiding this comment

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

I thought we had plumbed the correct data for this through the header?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

we missed the hex strings

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i will hardcode for this pr and fix after the snap

Copy link
Member

Choose a reason for hiding this comment

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

See #40895 we may want to fix for 5.0

@ericstj
Copy link
Member

ericstj commented Aug 18, 2020

And add a net5.0(-*) TargetFramework as appropriate?

Per offline conversation, this doesn't need to be done with the version change, but does need to happen when the TFM changes. The TFM change can be separate as it likely requires a bit more to make the SDK work with the new TFM. (EG: temporary KnownFrameworkReference)

Copy link
Member

Choose a reason for hiding this comment

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

Technically we should be setting baselineVersion for all packages. However it's likely less important here since we don't ever use PackageReferences to the Microsoft.Extensions packages and none of their versions are frozen (so all assembly refs will be to 6.0.0.0 and thus get the 6.0.0-* packages).

Copy link
Member

Choose a reason for hiding this comment

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

I think we still want to download the targeting pack if UseLocalTargetingRuntimePack=false. It's possible that the SDK doesn't carry it (once it moves to net6.0 for example).

Copy link
Member

Choose a reason for hiding this comment

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

This deserves a comment. Let's mention that this test assembly needs to run on the tool shared framework so it should reference the latest references. We build against tool shared framework's ref pack, run the generator on the tool shared framework, then execute the test on the test shared framework.

Copy link
Member

Choose a reason for hiding this comment

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

Not for this PR, but we should try to make this use $(ProductVersion) if possible.

@Anipik Anipik merged commit d9f0ba7 into dotnet:master Aug 20, 2020
@Anipik Anipik deleted the net6 branch August 20, 2020 00:23
@ghost ghost locked as resolved and limited conversation to collaborators Dec 7, 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