-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Allow references to specify metadata to skip finding dependencies in RAR #2716
Conversation
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.
Test coming?
// Targets that raise references from NuGet packages set FindDependencies=false to skip looking | ||
// for dependencies that they have already resolved and related files that they are responsible | ||
// for deploying. | ||
private static bool ShouldFindDependencies(Reference reference) |
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.
Should this be in Reference itself?
I was wondering if a more general name is suited. I want to experiment with this to turn off other RAR behaviour.
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.
Which other behaviours that are per-reference?
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.
When resolving a reference, RAR first looks near all the parents of that reference. If it finds nothing, then it starts asking the resolvers that were actually specified to RAR. I think this could be skipped when the reference is a nuget reference. For example, ProjA -> ProjB ->Nupkg. It's not worth looking for the Nupkg alongside ProjA or ProjB, and skip directly to the actual RAR resolvers. Though even in this case, the FindDependencies
name is still valid.
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.
@cdmihai I like that optimization
get | ||
{ | ||
string findDependencies = _primarySourceItem?.GetMetadata("FindDependencies"); | ||
return string.IsNullOrEmpty(findDependencies) ? true : findDependencies.Equals("true", StringComparison.OrdinalIgnoreCase); |
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.
Can you please cache this value? It traverses the metadata name, may new up a StringBuilder and other small things. Probably not a big gain though caching it.
0321193
to
90feae2
Compare
90feae2
to
9da1390
Compare
Code is ready for review, but still working on unit test |
{ | ||
FindDependenciesAndScatterFiles(reference, newEntries); | ||
SkippedFindingExternallyResolvedDependencies = true; |
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.
ComputeClosure clears out _references. This flag probably needs to be reset as well right?
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.
Done.
@@ -2146,6 +2160,8 @@ ReadMachineTypeFromPEHeader readMachineTypeFromPEHeader | |||
assemblyMetadataCache | |||
); | |||
|
|||
dependencyTable.FindDependenciesOfExternallyResolvedReferences = FindDependenciesOfExternallyResolvedReferences; |
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.
Quite the large constructor parameter list right? :)
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.
Yeah. Are you OK with this deviation?
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.
Yes, just for the sake of less churn. The large number of arguments seems bad enough and shadows this deviation :)
@cdmihai Tests are added |
@@ -1107,6 +1117,9 @@ string executableExtension | |||
// This is an assembly file, so we'll need to find dependencies later. | |||
DependenciesFound = false; | |||
|
|||
string externallyResolved = sourceItem.GetMetadata("ExternallyResolved"); | |||
ExternallyResolved = string.Equals(externallyResolved, "true", StringComparison.OrdinalIgnoreCase); | |||
|
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.
Nit: Can you use:
ExternallyResolved = MetadataConversionUtilities.TryConvertItemMetadataToBool(sourceItem, "ExternallyResolved")
Not used everywhere, but it already is elsewhere in the file so we should try to be consistent.
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.
That looks like it would be an order of magnitude more expensive, but once per reference is probably ok. I'll do it for consistency.
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.
Looks good!
/// <summary> | ||
/// Externally resolved references do not get their related files identified by RAR. In the common | ||
/// nuget assets case, RAR cannot be the one to identify what to copy because RAR sees only the | ||
/// compile-time assets and not the |
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.
Sentence ends in cliffhanger :)
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.
Fixed.
Perf looks good. Build: Time (ms)
Build: Memory (bytes)
|
SDK half: dotnet/sdk#1725
See there for perf numbers