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

In Legacy Package Ref case, use only per tfm dependencies #1652

Merged
merged 21 commits into from
Sep 8, 2017

Conversation

nkolev92
Copy link
Member

@nkolev92 nkolev92 commented Aug 15, 2017

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

@@ -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.
Copy link
Contributor

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.
Copy link
Contributor

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)
Copy link
Contributor

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.

Copy link
Member Author

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' ">
Copy link
Contributor

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?

Copy link
Member Author

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.

@nkolev92
Copy link
Member Author

@@ -427,12 +427,8 @@ Copyright (c) .NET Foundation. All rights reserved.
DependsOnTargets="_GetRestoreProjectStyle;_GetRestoreTargetFrameworksOutput"
Returns="@(_RestoreTargetFrameworkItems)">

<PropertyGroup>
<_RestoreTargetFrameworkItemsHasValues Condition=" '$(TargetFramework)' != '' OR '$(TargetFrameworks)' != '' ">true</_RestoreTargetFrameworkItemsHasValues>
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

@rohit21agrawal rohit21agrawal left a 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)
Copy link
Contributor

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

Copy link
Contributor

@jainaashish jainaashish left a 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.

@nkolev92
Copy link
Member Author

@jainaashish 🔔

Copy link
Contributor

@jainaashish jainaashish left a comment

Choose a reason for hiding this comment

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

LGTM

@nkolev92
Copy link
Member Author

This PR currently has some failing EndToEnd tests due to the following issues:
NuGet/Home#5778 and NuGet/Home#5777
Once the templates have been fixed 5778, this should be safe to merge in.

Depending on the decision in NuGet/Home#5777 there might need to improvements in this, but that's a separate issue.

@nkolev92 nkolev92 force-pushed the dev-nkolev92-fixlegacynoop branch from fb755c9 to bd9c195 Compare September 6, 2017 21:48
Copy link
Member

@emgarten emgarten left a 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

@nkolev92
Copy link
Member Author

nkolev92 commented Sep 7, 2017

@emgarten 🔔

@@ -330,7 +330,6 @@ private static PackageReference ToPackageReference(LibraryDependency library, Nu
Owners = new string[] { },
Tags = new string[] { },
ContentFiles = new string[] { },
Dependencies = packageReferences,
FilePath = _projectFullPath,
Copy link
Member

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?

Copy link
Member

Choose a reason for hiding this comment

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

I see 😄

Copy link
Member

@emgarten emgarten left a comment

Choose a reason for hiding this comment

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

🚀

@nkolev92 nkolev92 merged commit f9569ac into dev Sep 8, 2017
@nkolev92 nkolev92 deleted the dev-nkolev92-fixlegacynoop branch September 21, 2017 23:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants