Conversation
…sts for conditional package operations
4ee220c to
e91d377
Compare
src/NuGet.Core/NuGet.PackageManagement/BuildIntegration/BuildIntegratedProjectAction.cs
Outdated
Show resolved
Hide resolved
src/NuGet.Core/NuGet.PackageManagement/BuildIntegration/BuildIntegratedProjectAction.cs
Show resolved
Hide resolved
src/NuGet.Core/NuGet.PackageManagement/BuildIntegration/BuildIntegratedProjectAction.cs
Show resolved
Hide resolved
| #pragma warning disable CS0618 // Type or member is obsolete | ||
| OriginalActions = originalActionsAndInstallationContexts.Select(e => e.Item1).ToList(); | ||
| InstallationContext = originalActionsAndInstallationContexts[0].Item2; | ||
| #pragma warning restore CS0618 // Type or member is obsolete |
There was a problem hiding this comment.
I'm really curious to understand why we should access the obsolete members here. We already assigned the new property ActionAndContextList with the correct value in this constructor, which isn't obsolete. And have we done the same in the constructor that is marked as obsolete in this PR.
There was a problem hiding this comment.
The constructor is new, there's a new property, but that doesn't mean that the old contract should be broken.
Normally, if this wasn't a public API, I'd remove the old properties, but that's not possible without a breaking change currently.
So until then, we make sure that the type is correctly populated.
There was a problem hiding this comment.
The two properties OriginalActions and InstallationContext are currently unused in the product code. If a caller uses the new constructor, we'll assign a value to the newly introduced property in this PR, ActionAndContextList, which the product code references. However, if the caller uses the old constructor, we'll generate the ActionAndContextList property using OriginalActions and InstallationContext. This new property will then be used throughout the rest of the product code. Therefore, I'm uncertain about the necessity of assigning values to the old or obsolete properties in the new constructor.
There was a problem hiding this comment.
We don't know who/how people use our code unfortunately.
If people say we're not worried about that, I can remove it, but I was erring on the cautious side.
src/NuGet.Core/NuGet.PackageManagement/BuildIntegration/BuildIntegratedProjectAction.cs
Show resolved
Hide resolved
test/NuGet.Core.Tests/NuGet.PackageManagement.Test/NuGetPackageManagerUtilityTests.cs
Show resolved
Hide resolved
test/NuGet.Core.Tests/NuGet.PackageManagement.Test/NuGetPackageManagerUtilityTests.cs
Show resolved
Hide resolved
...Get.Core.Tests/NuGet.PackageManagement.Test/PackageReferenceBasedNuGetPackageManagerTests.cs
Show resolved
Hide resolved
|
@kartheekp-ms Note that I've marked comments where my next commit will resolve the feedback as |
|
I am also wondering if we need a new (or update existing) apex test to assert the new behavior. |
I think I am done for now. Please feel free to push new commit(s). May be out of scope for this PR. If I click on "Update" a package version in the "Installed" tab, then the versions in the csproj are not updated correctly when there are multiple target frameworks. I can open a separate bug for this scenario. |
There's no multi targeted templates, so that makes Apex tests extremely difficult to add. .NET templates in previews also require constant source updates right now as packages are not always published to nuget.org, or a source that we control. Created an issue for that https://github.com/NuGet/Client.Engineering/issues/2589. |
With my changes? If you want to consider it out scope, you can just create an issue and assign it to me, and I can validate that afterwards. |
|
@kartheekp-ms For example, I tested a similar scenario as yours, but the conditions are on the package reference item instead, and that does work! I'll create an issue for follow up. That change may not be on the nuget side. |
|
Actually, nevermind you have 2 frameworks in your test and I have 3. I'll create a follow up for that. |
Has the follow-up issue been created? |
|
No, I was waiting for approval on this first. I created it now NuGet/Home#13034 |



Bug
Fixes: NuGet/Home#4681
Regression? Last working version:
Description
Conditional package updating was previously fixed in fed7892.
This PR fixes the
update allscenario, ensuring all packages are updated instead of just 1.This PR also improves the tests cases for the scenarios.
Some technical details to help with the review of this PR:
PR Checklist
PR has a meaningful title
PR has a linked issue.
Described changes
Tests
Documentation