-
Notifications
You must be signed in to change notification settings - Fork 696
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
In Legacy Package Ref case, use only per tfm dependencies #1652
Conversation
64ddc9d
to
fdf51d5
Compare
@@ -664,12 +664,6 @@ private void PopulateProjectAndPackageReferences(PackageBuilder packageBuilder, | |||
// From the package spec, we know the direct package dependencies of this project. | |||
foreach (var framework in assetsFile.PackageSpec.TargetFrameworks) | |||
{ | |||
// First, add each of the generic package dependencies to the framework-specific list. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
investigate if this is really necessary.
@@ -1,4 +1,4 @@ | |||
// Copyright (c) .NET Foundation. All rights reserved. | |||
// Copyright (c) .NET Foundation. All rights reserved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
revert this one.
@@ -13,8 +13,11 @@ namespace NuGet.ProjectModel | |||
{ | |||
public static class PackageSpecOperations | |||
{ | |||
public static void AddOrUpdateDependency(PackageSpec spec, PackageDependency dependency) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we are removing a public api that has potential to break sdk/cli when they update.
i would prefer if you added an overload and make this method call the overloaded method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I checked that, and it's not used.
I'd normally prefer to cleanup APIs that aren't super important for other users, but I'll revert this.
<!-- Only return values for NETCore PackageReference projects --> | ||
<ItemGroup Condition=" '$(RestoreProjectStyle)' == 'PackageReference' AND '$(_RestoreTargetFrameworkItemsHasValues)' == 'true' "> | ||
<!-- Only return values for PackageReference projects --> | ||
<ItemGroup Condition=" '$(RestoreProjectStyle)' == 'PackageReference' AND '$(RestoreProjectStyle)' == 'PackageReference' "> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do you need the same condition twice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't lol.
Nice catch.
I misread it completely.
@@ -427,12 +427,8 @@ Copyright (c) .NET Foundation. All rights reserved. | |||
DependsOnTargets="_GetRestoreProjectStyle;_GetRestoreTargetFrameworksOutput" | |||
Returns="@(_RestoreTargetFrameworkItems)"> | |||
|
|||
<PropertyGroup> | |||
<_RestoreTargetFrameworkItemsHasValues Condition=" '$(TargetFramework)' != '' OR '$(TargetFrameworks)' != '' ">true</_RestoreTargetFrameworkItemsHasValues> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this isn't used anywhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just a local one used in the below item group as a condition. It was used to restrict setting the target frameworks to net core only.
By changing it now the target frameworks are set in the legacy case as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just one minor question, otherwise looks good!
@@ -2381,7 +2381,14 @@ var projectUniqueNamesForBuildIntToUpdate | |||
} | |||
else if (action.NuGetProjectActionType == NuGetProjectActionType.Install) | |||
{ | |||
PackageSpecOperations.AddOrUpdateDependency(updatedPackageSpec, action.PackageIdentity); | |||
if (updatedPackageSpec.RestoreMetadata.ProjectStyle == ProjectStyle.ProjectJson) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make more sense if you check for PackageReference
and pass tfms. And else case use the old call. That will keep the existing behavior and only change PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small correction to be consistent with existing behavior. Otherwise looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR currently has some failing EndToEnd tests due to the following issues: Depending on the decision in NuGet/Home#5777 there might need to improvements in this, but that's a separate issue. |
02f3f86
to
fb755c9
Compare
fb755c9
to
bd9c195
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make this change in MSBuildRestoreUtility.AddPackageReferences
…Build related perf concerns
@@ -330,7 +330,6 @@ private static PackageReference ToPackageReference(LibraryDependency library, Nu | |||
Owners = new string[] { }, | |||
Tags = new string[] { }, | |||
ContentFiles = new string[] { }, | |||
Dependencies = packageReferences, | |||
FilePath = _projectFullPath, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where do the package dependencies get populated now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
This PR partially addresses NuGet/Home#5444
To fully fix the above issue, I will create another PR which specifically targets the way we calculate the hash for no-op comparison.
In the case of Legacy Package Reference our code has been used inconsistently where in most cases we used top level dependencies, while we built the package spec with both top level/ per tfm in VS.
In the exe only top level dependencies were used.
Now I have changed all of those to use Per TFM dependencies only. This will make the dg specs created among VS and exe "almost" the same.
Scenario Change
This changes the dependency flowing behavior when projects are incompatible.
say, net45 project references a net46 projects, before this change, we'd throw an incompatibility error during restore but also flow the dependencies. Now they won't flow since the frameworks are incompatible.
This is not a big concern cause no one could rely on this, because the scenario is not buildable