[Blazor] Add unsupported compat switch for property injection #63493
+16
−8
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There was a problem hiding this comment.
Pull Request Overview
This PR adds an unsupported AppContext switch to disable property injection in Blazor's default component factory. The feature allows custom component activators to take full control of property injection by bypassing the framework's built-in @inject property handling.
Key changes:
- Introduces
Microsoft.AspNetCore.Components.Unsupported.DisablePropertyInjectionAppContext switch - Conditionally skips property injection in
InstantiateComponentmethod when switch is enabled - Maintains backward compatibility with opt-in behavior
maraf
approved these changes
Sep 2, 2025
lewing
approved these changes
Sep 2, 2025
lewing
deleted the
javiercn/disable-property-injection-via-app-context-switch
branch
wtgodbe
added a commit
that referenced
this pull request
Sep 3, 2025
* Merge pull request #63458 from dotnet/darc-release/10.0-0b5f1d61-512f-46bf-9db1-6245ce11f284 [release/10.0] Source code updates from dotnet/dotnet * Add unsupported compat switch for property injection (#63493) * [release/10.0] Remove duplicate RedirectManager injection in Blazor Web App ChangePassword template (#63452) * Initial plan * Fix duplicate RedirectManager injection in ChangePassword.razor template Co-authored-by: ilonatommy <[email protected]> --------- Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: ilonatommy <[email protected]> * Update .NET SDK version in global.json --------- Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Javier Calvarro Nelson <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <[email protected]> Co-authored-by: ilonatommy <[email protected]> Co-authored-by: William Godbe <[email protected]>
@javiercn Please open an issue for adding the public API so we don't lose track of it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add switch to disable property injection in default component factory
Adds an unsupported app context switch to disable property injection within the default component factory. The switch prevents injection of
@injectproperties so a custom activator can handle activation and property population.Description
Adds a new, unsupported AppContext switch that disables property injection for components activated through the default component factory. When enabled, the framework will skip injecting
@injectproperties so that a custom activator (for example, one backed by a different DI container) can perform property activation instead.This change addresses the scenario where component property activation currently always uses the app's DI container and cannot be overridden by custom activators. With the switch, custom implementations that rely on a separate container can take full control of property activation.
Customer Impact
This is not a switch for public consumption but rather a switch we are providing to support first parties in 10.0. On 11.0 we will add a public API to support this scenario and remove this switch.
Regression?
Risk
Justification: The change is gated behind an unsupported AppContext switch and is opt-in. It does not change the default behavior and only affects activation when the switch is explicitly enabled.
Verification
Packaging changes reviewed?