RootComponentTypeCache Prevents Dynamic Component Regeneration in Interactive Server Mode (Still)

[chaseaucoin]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I am still having the same issue as in #60573 but it was marked closed with a "fix" that did not fix it. I am unsure of the protocol to get it re-opened I have tried to contact the person who closed it but I haven't had any response in a month and a half.

This impacts our ability to create dynamic components on the fly and from additional comments it looks like it is impacting the dynamic component render as well.

Feel free to remove this ticket if you can direct me to the correct procedure for the future, I'm happy to use the appropriate channel.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

[javiercn]

@chaseaucoin thanks for contacting us.

Filing an issue is always the right way to raise something with us, you can mention existing issues, and we can easily de-duplicate against existing issues.

I realize now that your ask has nothing to do with hotreload.

I take it that you have essentially implemented your own version of runtime compilation. Is that a fair comparison?

[ppagano-dev]

As mentioned in #60573, I think this is the root cause of my issues, having unloaded collectible assembly load contexts kept alive forever by blazor. I've a repo describing the case: LoaderTest. @javiercn is this the right way to do or should I proceed in a different way? Thanks.

[chaseaucoin]

I realize now that your ask has nothing to do with hotreload.

I take it that you have essentially implemented your own version of runtime compilation. Is that a fair comparison?

@javiercn

Thanks for the follow-up. Yes, that's correct. Our system dynamically compiles and loads Blazor components at runtime to support on-the-fly customization of pages and UI elements. To work around the current limitations in caching, we've resorted to using reflection to access and clear internal structures like RootComponentTypeCache. That approach is brittle and not something we’re comfortable relying on long-term. We would strongly prefer a supported, reflection-free mechanism. From what we've seen so far, this seems feasible if a small public API surface were introduced.

The overall approach works, but the current caching behavior, especially within RootComponentTypeCache and related internals, makes it difficult to reliably recompile and render updated components. The inability to reset or evict items from these caches at runtime prevents expected behaviors for dynamically emitted types.

We understand there may be architectural or performance reasons for keeping these caches and types internal. Even so, we hope there might be a supported way forward for scenarios like ours. One option could be a minimal public-facing service that can be injected and used to invalidate the relevant cache entries. This could involve full cache invalidation, or a more selective approach, such as evicting items by type or assembly. Full invalidation would already help, but selective eviction would allow dynamic compilation scenarios to work more efficiently alongside other parts of the app.

If exposing the cache directly is not viable, perhaps a structured component registration API could provide a cleaner abstraction. That would allow runtime systems to explicitly re-register components without relying on reflection.

We appreciate the improvements made so far for Hot Reload scenarios, and we would be happy to provide more detail or explore potential implementation options if helpful.

Thanks again for your time and engagement with this.

[chaseaucoin]

As a related thought, a public cache invalidation or component registration mechanism could also benefit Hot Reload workflows during development.

For example, in projects where components are structured in separate Razor Class Libraries (RCLs), this would open the door to more efficient reload behavior. If only a component RCL changes, and the host or primary application assemblies remain untouched, a system that supports selective invalidation could reload just that updated assembly. This would avoid unnecessary recomputation and allow developers to see changes almost instantly.

It’s a bit outside the scope of our original runtime use case, but depending on how a solution is structured, it could also unlock significantly faster Hot Reload cycles and smoother edit-and-refresh experiences for modular Blazor apps.

Just some additional food for thought in case broader development tooling benefits are of interest.

[chaseaucoin]

@javiercn I have given my feedback.

[javiercn]

@chaseaucoin thanks for the additional details.

This is definitely a different scenario than hot reload. In general, none of our frameworks support runtime compilation of views for production workloads. Not even MVC and Razor Pages (which shipped a runtime compilation feature) are recommended for production workloads.

This is not a direction we plan to change in the short term, supporting this type of scenario goes well beyond exposing a method or primitive to clearing a concrete cache and is something we would want to have a holistic design for.

Supporting reloading of runtime compiled components is not something we plan to support now or very possibly in the future. You can continue to use whatever method you are using to make it work, but we make no guarantees that it won't break in the future as we make changes in the framework to support new functionality.