Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
/ corefx Public archive

Lift Microsoft.NETCore.Targets to reduce v1 conflicts #18341

Merged
merged 2 commits into from
Apr 13, 2017

Conversation

ericstj
Copy link
Member

@ericstj ericstj commented Apr 13, 2017

Include the update to v1 lineup package, which now has no runtime package
mappings.

This will reduce the number of packages downloaded when mixing v1 and
later packages as well as reduce our dependence on conflict resolution
for dropping those v1 runtime packages.

Fixes #18088

Requires dotnet/core-setup#2053

/cc @weshaggard @joperezr

ericstj added 2 commits April 13, 2017 11:07
Include the update to v1 lineup package, which now has no runtime package
mappings.

This will reduce the number of packages downloaded when mixing v1 and
later packages as well as reduce our dependence on conflict resolution
for dropping those v1 runtime packages.
@ericstj
Copy link
Member Author

ericstj commented Apr 13, 2017

@dotnet-bot test this please

@@ -0,0 +1,92 @@
{
"supports": {
Copy link
Member

Choose a reason for hiding this comment

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

Is there any reason to keep these supports clauses?

Copy link
Member Author

Choose a reason for hiding this comment

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

Folks who use them would be broken if we removed them. I felt like removing them was an unnecessary breaking change.

packages as well as reduce our dependence on conflict resolution for dropping
those v1 runtime packages -->
<Dependency Condition="'$(IsLineupPackage)' == 'true'" Include="Microsoft.NETCore.Targets">
<Version>2.0.0</Version>
Copy link
Member

Choose a reason for hiding this comment

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

Any reason to not be a ProjectReference as opposed to hardcoding the version? Also is there much reason to reference this in the private transport packages?

Copy link
Member Author

@ericstj ericstj Apr 13, 2017

Choose a reason for hiding this comment

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

reason to not be a ProjectReference

It was what we were doing for platforms and it reduces a bit of build time. I thought about this when making the change and I didn't expect us to ever update this dependency. In fact, we'll likely delete the package authoring after 2.0, but keep the reference.

reason to reference this in the private transport packages

I'm just using that to flow the dependency, we could instead add the reference to the package in core-setup if we wanted.

@ericstj
Copy link
Member Author

ericstj commented Apr 13, 2017

Merging. OSX build seems to be hitting lab issues again.

@ericstj ericstj merged commit 1f58697 into dotnet:master Apr 13, 2017
@karelz karelz modified the milestone: 2.0.0 Apr 15, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants