dotnet/aspnetcore · error · InvalidOperationException

The value of cannot be changed dynamically.

Error message

The value of {nameof(IsFixed)} cannot be changed dynamically.

What it means

CascadingValue's IsFixed parameter is captured on the first render and cannot change for the component's lifetime. IsFixed controls whether subscribers are notified of value changes, so flipping it mid-lifetime would break the notification contract and is rejected with InvalidOperationException.

Solutions

Keep IsFixed constant for the lifetime of the CascadingValue instance.
Use two separate CascadingValue instances if you need both fixed and non-fixed modes.
For dynamic values, keep IsFixed="false" and update the Value instead of toggling IsFixed.

Example fix

// before
<CascadingValue Value="@val" IsFixed="@isFixedToggle">
// after
<CascadingValue Value="@val" IsFixed="false">

Defensive patterns

Strategy: validation

Validate before calling

// Treat IsFixed as a constant; do not bind it to mutable state.
// In Razor, use a literal or a readonly field:
<CascadingValue Value="@val" IsFixed="false">

Prevention

Never bind IsFixed to a variable that can change between renders.
Document the intended IsFixed value near the CascadingValue usage.
Use CascadingValueSource for dynamic values rather than toggling IsFixed.

When it happens

Trigger: First render with IsFixed="false" then a subsequent render with IsFixed="true" (or vice versa). Typically happens when IsFixed is bound to a variable that changes between renders.

Common situations: Conditionally toggling IsFixed based on data, refactoring a non-fixed value into a fixed one without restarting the component, or a parent re-rendering with a different IsFixed value.

Related errors

AI-assisted analysis of dotnet/aspnetcore@3600ca084e (2026-08-11). Data as JSON: /api/errors/f2e6dffa20eaa281. Report an issue: GitHub.

Appendix: source

Thrown at src/Components/Components/src/CascadingValue.cs:96

                Name = (string)parameter.Value;
                if (string.IsNullOrEmpty(Name))
                {
                    throw new ArgumentException($"The parameter '{nameof(Name)}' for component '{nameof(CascadingValue<TValue>)}' does not allow null or empty values.");
                }
            }
            else if (parameter.Name.Equals(nameof(IsFixed), StringComparison.OrdinalIgnoreCase))
            {
                IsFixed = (bool)parameter.Value;
            }
            else
            {
                throw new ArgumentException($"The component '{nameof(CascadingValue<TValue>)}' does not accept a parameter with the name '{parameter.Name}'.");
            }
        }

        if (_hasSetParametersPreviously && IsFixed != previousFixed)
        {
            throw new InvalidOperationException($"The value of {nameof(IsFixed)} cannot be changed dynamically.");
        }

        _hasSetParametersPreviously = true;

        // It's OK for the value to be null, but some "Value" param must be supplied
        // because it serves no useful purpose to have a <CascadingValue> otherwise.
        if (!hasSuppliedValue)
        {
            throw new ArgumentException($"Missing required parameter '{nameof(Value)}' for component '{GetType().Name}'.");
        }

        // Rendering is most efficient when things are queued from rootmost to leafmost.
        // Given a components A (parent) -> B (child), you want them to be queued in order
        // [A, B] because if you had [B, A], then the render for A might change B's params
        // making it render again, so you'd render [B, A, B], which is wasteful.
        // At some point we might consider making the render queue actually enforce this
        // ordering during insertion.
        //

View on GitHub (pinned to 3600ca084e)