Skip to content

Comments

Fix edit in one project not being reflected in consuming project#12439

Merged
chsienki merged 4 commits intodotnet:mainfrom
chsienki:issue/12316
Nov 3, 2025
Merged

Fix edit in one project not being reflected in consuming project#12439
chsienki merged 4 commits intodotnet:mainfrom
chsienki:issue/12316

Conversation

@chsienki
Copy link
Member

@chsienki chsienki commented Nov 3, 2025

When referencing an RCL from another project, the MetadataReference passed to the generator is in fact a CompilationReference. 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 two CompilationReferences we would retreive Guid.Zero for 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

Iterate the modules in both assemblies, if we don't have an MVID (like for ca compilation reference) then consider them not equal.
@chsienki chsienki requested a review from a team as a code owner November 3, 2025 21:26
Copy link
Member

@davidwengier davidwengier left a comment

Choose a reason for hiding this comment

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

🎉🎉🎉

@chsienki chsienki changed the title Fix rename in one project not being reflected in consuming project Fix edit in one project not being reflected in consuming project Nov 3, 2025
@chsienki chsienki enabled auto-merge (squash) November 3, 2025 21:45
Comment on lines +182 to +187
var oldModules = oldAssembly.Modules.ToArray();
var newModules = newAssembly.Modules.ToArray();
if (oldModules.Length != newModules.Length)
{
return false;
}
Copy link
Member

Choose a reason for hiding this comment

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

grumble grumble Why does IAssemblySymbol.Modules return an IEnumerable<IModuleSymbol> when it's always backed by an ImmutableArray<IModuleSymbol>? grumble grumble

(no change requested)

Comment on lines +189 to 203
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;
}
}
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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)

Copy link
Member

Choose a reason for hiding this comment

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

I gave you an out with my third question BTW. You could have typed way fewer words. 😁

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.

VS2026 .NET 9 Blazor Component Errors and Debug Loop

3 participants