Avoid NuGet restore cycles#8239
Avoid NuGet restore cycles#8239ocallesp merged 4 commits intodotnet:mainfrom ocallesp:AvoidNuGetRestoreCycles
Conversation
|
Any updates on this change @ocallesp? |
|
@ocalles You're getting build failures with these changes. |
Fixed. |
|
Tests: |
Today I add a new commit with the implementation of InfoBar. This pr is complete. Waiting for reviewers and approval |
|
@ocallesp - not required for the initial merge but anyways we can add telemetry around this for when we detect a cyclic restore? Will help determine how often our users run into this scenario, we detect it & display the infobar |
There was a problem hiding this comment.
think it would be helpful to add additional properties in addition to cycledetected. So have the event name as :
/nugetrestore/cycledetection and properties like vs.projectsystem.managed.nugetrestore.cycledetection.cycledetected, vs.projectsystem.managed.nugetrestore.cycledetection.durationmillis, vs.projectsystem.managed.nugetrestore.cycledetection.successfulrestorecount,
vs.projectsystem.managed.nugetrestore.cycledetection.projectid or vs.projectsystem.managed.nugetrestore.cycledetection.solutionid perhaps. Any additional items you think may be useful to help troubleshoot when we detect a cyclical restore.
There was a problem hiding this comment.
I believe project id and solutionid are sent automatically. Duration and succesffulrestorecount would be nice. I think succesffulrestorecount will be unreliable as I believe we must stop as soon as a cycle is detected.
There was a problem hiding this comment.
Are you sure IsInServerMode works off the ui thread? This is invoked on a arbitrary thread in cycle detector.
There was a problem hiding this comment.
IsInServerMode -> is this to account for Nexus based scenarios? Do we need to explicitly call out a NotSupportedException when IsInServerMode = true?
There was a problem hiding this comment.
This was originally to account for Nexus scenarios, yes, and as we don't really have a server SKU under active development it probably doesn't matter much. I think it's reasonable to throw an exception if we are in server mode, and also agree with @jacdavis that we need to verify IsInServerMode is ok to call from an arbitrary thread, and/or transition to the UI thread.
There was a problem hiding this comment.
I added the hash _lookupTable to improve the search to O(1)
There was a problem hiding this comment.
I'm still not convinced a queue is the correct data structure here. Can you please call me to discuss as requested?
There was a problem hiding this comment.
This was originally to account for Nexus scenarios, yes, and as we don't really have a server SKU under active development it probably doesn't matter much. I think it's reasonable to throw an exception if we are in server mode, and also agree with @jacdavis that we need to verify IsInServerMode is ok to call from an arbitrary thread, and/or transition to the UI thread.
This a mef exported service that displays an infoBar in the main windows.
The cycle detector is based on hashes calculated from restore inputs. This algorithm detects patterns A -> B -> A Time O(1) search Time O(1) add Time O(1) delete Space O(1)
|
Some of the pending code review suggestions will be fixed as part of #8389 |
Fixes dotnet#8504 This interface and its implementation (`VSShellServices`) was copied from CPS in dotnet#8239, but nothing ever initialised the implementation. This change changes the API so that these values can be lazily implemented and efficiently queried.
Fixes #8326
Avoid infinite NuGet restores.
Scenario:
Projects might have a package that sets
AssetTargetsFallbackvalue that can cause a certainPackageReferenceto be included. This package contains a props file that changed theAssetTargetFallbackproperty value, and thePackageReferenceCondition was no longer true, causing it to be removed. Once removed, theAssetTargetFallbackvalue from thecsprojwas used again, causing an infinite restore -> design time build -> restore loop.This change:
Since DotNet ProjectSystem can detect changes in NuGet restores by calculating a hash, we can use this hash to detect changes in
AssetTargetFallBackand check when this value gets repeated.This pr makes use of the
NuGetRestoreCycleDetectorto keep the last N hashes, and once it detects a repeated value (cycle) Dotnet ProjectSystem can stop NuGet restores.Microsoft Reviewers: Open in CodeFlow