Use MetadataUpdateHandlerAttribute in Blazor

[pranavkm]

• Annotate HotReloadManager to use the new attribute
• Add support for invoking the new attribute in WASM's hot reload

[pranavkm]

Ignore this. Our targets had a bug

---

@Eilon I'm seeing an error building the Wpf app that suggests it's using an older targeting pack:

D:\temp\aspnetcore\.dotnet\sdk\6.0.100-preview.3.21168.19\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets(222,9): error MC1000: Unknown build error, 'Could not find type 'System.Reflection.Metadata.MetadataUpdateHandlerAttribute' in assembly 'D:\temp\aspnetcore\.dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.3.21167.1\ref\net6.0\System.Runtime.Loader.dll'.'  [D:\temp\aspnetcore\src\Components\WebView\Samples\BlazorWpfApp\BlazorWpfApp.csproj]

Just making sure it's not intentionally pointing to an older version.

[pranavkm]

FYI @stephentoub

[captainsafia]

Is this change related to #31817 (comment)? Maybe add a comment to clarify it here...

[captainsafia]

So, if I understand correctly beforeUpdates and afterUpdates are handlers that can be invoked before and after deltas are applied. What are some scenarios where they are used?

Also -- why does this take a null value instead of just being a parameterless method?

[stephentoub]

What are some scenarios where they are used?

e.g. to clear corelib's reflection cache, to clear JsonSerializer's cache of reflection data, to refresh a binding in a UI, etc.

why does this take a null value instead of just being a parameterless method?

The plan is for the agent to pass an array of the types being updated, if available, but we don't have that information yet. The pattern will likely evolve over the next few months as we find out more about what various handlers need.

[ghost]

Hello @pranavkm!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[SteveSandersonMS]

@pranavkm Since I was out last week I missed whatever design discussions brought us here. It all looks good, but can I check my understanding of the high-level idea is correct?

It looks as if:

• MetadataUpdateHandlerAttribute is defined in the BCL, so is common to all app frameworks
• But, each app framework is responsible for separately implementing its own logic to discover all usages of that attribute, and implement its own logic to find both the BeforeUpdate and AfterUpdate methods and invoke them at the right times before and after applying the update

If this is correct, it's totally fine, though there is of course a concern that different app frameworks might not all implement it in the same way. Not a massive issue but was there consideration given to putting this logic inside AssemblyExtensions.ApplyUpdate so that it was independent of each app framework?

To be super clear I'm [update] not suggesting this is a problem - this is just me trying to get in sync with the groupthink on this subject.

[stephentoub]

To be super clear I'm suggesting this is a problem

Is this missing a "not"? 😄

But, each app framework is responsible for separately implementing its own logic

Each agent is. Some app models will have their own, some will share.

was there consideration given to putting this logic inside AssemblyExtensions.ApplyUpdate so that it was independent of each app framework?

Yes, I'd actually suggested we do this. There was some concern expressed (I believe by @jkotas?) that this would tie the runtime too much to the specific pattern and make it harder to evolve. The attribute in the core library just specifies the type that implements the pattern, but doesn't dictate its shape. @jkotas?

(As an aside, we need to lock down soon on the initial shape of the pattern. I'll open an issue for that.)

[ghost]

Hi @stephentoub. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[SteveSandersonMS]

Is this missing a "not"? 😄

Yes, sorry! Updated.

Thanks for the additional info.

[jkotas]

There was some concern expressed (I believe by @jkotas?) that this would tie the runtime too much to the specific pattern and make it harder to evolve.

Yes, see dotnet/runtime#49361 (comment) and other comments in that issue.

MetadataUpdateHandlerAttribute is defined in the BCL, so is common to all app frameworks

Nit: Assemblies that target netstandard should be able define a local copy of the attribute if they need to.

[ghost]

Hi @jkotas. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.