Fix edit in one project not being reflected in consuming project#12439
Fix edit in one project not being reflected in consuming project#12439chsienki merged 4 commits intodotnet:mainfrom
Conversation
Iterate the modules in both assemblies, if we don't have an MVID (like for ca compilation reference) then consider them not equal.
| var oldModules = oldAssembly.Modules.ToArray(); | ||
| var newModules = newAssembly.Modules.ToArray(); | ||
| if (oldModules.Length != newModules.Length) | ||
| { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
grumble grumble Why does IAssemblySymbol.Modules return an IEnumerable<IModuleSymbol> when it's always backed by an ImmutableArray<IModuleSymbol>? grumble grumble
(no change requested)
| for (int i = 0; i < oldModules.Length; i++) | ||
| { | ||
| var oldMetadata = oldModules[i].GetMetadata(); | ||
| var newMetadata = newModules[i].GetMetadata(); | ||
|
|
||
| if (oldMetadata is null || newMetadata is null) | ||
| { | ||
| return false; | ||
| } | ||
|
|
||
| if (oldMetadata.GetModuleVersionId() != newMetadata.GetModuleVersionId()) | ||
| { | ||
| return false; | ||
| } | ||
| } |
There was a problem hiding this comment.
Is the order of modules in an assembly stable? Or, should two assemblies be considered identical if their modules are in a different order? Or, should I be quiet and remember that multi-module assemblies are an uncommon scenario? I'm guessing your answer will be an affirmative to the third question.
There was a problem hiding this comment.
Heh, AFAIK the modules should be stable, and I would assume if they had moved around, we would need to re-run discovery anyway as there are odd initialization things that can change, I think. If we were re-running when we shouldn't, that's obviously a potential perf hit, but not a correctness one at least.
Generally though it's super rare to actually have multiple modules in an assembly (and I believe it's not even possible in modern .NET)
There was a problem hiding this comment.
I gave you an out with my third question BTW. You could have typed way fewer words. 😁
When referencing an RCL from another project, the
MetadataReferencepassed to the generator is in fact aCompilationReference. As these don't exist on disk, they don't have an MVID.The generator logic that checks if references have changed compares the MVIDs of each module in an assembly. If it couldn't find one, it returned
Guid.Zero. This meant when comparing twoCompilationReferences we would retreiveGuid.Zerofor both of them, and then consider that to be equal.Instead, we loop over each module and try and get it's MVID. If we can't get an MVID then we consider them to not be equal.
Note: that in the case the two compilation references are equal, we'll return true much earlier on via ReferenceEquals (updated test to include that).
Fixes #12316