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

Adding transitive project references based on target framework #15124

Merged
3 commits merged into from
Jan 15, 2021

Conversation

sfoslund
Copy link
Member

@sfoslund sfoslund commented Dec 30, 2020

Fixes #1227

@sfoslund sfoslund requested a review from dsplaisted December 31, 2020 16:32
Comment on lines 144 to 145
if (string.IsNullOrEmpty(group.FrameworkName) || string.IsNullOrEmpty(frameworkAlias) || group.FrameworkName.Equals(frameworkAlias) ||
NuGetUtils.ParseFrameworkName(group.FrameworkName.Split('/').First()).DotNetFrameworkName.Equals(NuGetUtils.ParseFrameworkName(frameworkAlias).DotNetFrameworkName))
Copy link
Member

Choose a reason for hiding this comment

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

Do we need to check if group.FrameworkName or frameworkAlias are empty? Shouldn't they always have values?

Also, I think that eventually we should not need to parse these to compare them. I think that eventually the dependency group's FrameworkName should match the target framework alias exactly. However, currently it doesn't. For now I would factor out the match calculation into a helper method to make it a bit easier to change later.

@nkolev92 @zkat Do you agree that when NuGet supports generalized target framework aliasing, that the key for the dependency group would change to be the target framework alias? Is there an issue for that we should link?

Copy link
Member Author

Choose a reason for hiding this comment

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

The target framework isn't marked as a required input for one of the tasks that uses this extension, so this guards against the case where it isn't provided. Without it we're breaking several existing tests.

Copy link
Contributor

Choose a reason for hiding this comment

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

Do you agree that when NuGet supports generalized target framework aliasing, that the key for the dependency group would change to be the target framework alias? Is there an issue for that we should link?

Not sure what the key is in this case. Can you please elaborate a bit?
Probably related NuGet/Home#5154

@sfoslund
Copy link
Member Author

sfoslund commented Jan 7, 2021

@dsplaisted does this look okay to you or do you have any more feedback?

@sfoslund sfoslund requested review from dsplaisted and wli3 January 11, 2021 16:40
@sfoslund sfoslund added auto-merge Automatically merge PR once CI passes. Auto-Merge If Tests Pass labels Jan 14, 2021
@ghost
Copy link

ghost commented Jan 14, 2021

Hello @sfoslund!

Because this pull request has the Auto-Merge If Tests Pass 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.

@ghost ghost merged commit 80e6bf8 into dotnet:master Jan 15, 2021
@sfoslund sfoslund deleted the MultiTFMProjRef5 branch January 15, 2021 00:35
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Auto-Merge If Tests Pass auto-merge Automatically merge PR once CI passes.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Conditional project references fail when targeting multiple TFMs
3 participants