dotnet/wpf · error · InvalidOperationException

Can't Assign to Known Member attributes

Error message

Can't Assign to Known Member attributes

What it means

WpfKnownMember metadata objects become frozen after initialization; CheckFrozen throws InvalidOperationException "Can't Assign to Known Member attributes" when any property setter (ReadOnly, HasSpecialTypeConverter, Ambient, IsReadPrivate, IsWritePrivate, SetDelegate) is invoked on a frozen member. Known-member tables are immutable by design once the schema is sealed.

Solutions

  1. Set all member attributes during construction/table-building, before the member is frozen (before it is handed to the schema/lookup pipeline).
  2. Don't mutate cached WpfKnownMember instances — create your own XamlMember subclass with the desired overrides instead.
  3. If you need per-case behavior, wrap the member with a custom XamlMember that overrides LookupIsReadOnly/LookupTypeConverter etc.
  4. Check for double initialization of the known-types table in your hosting code.

Example fix

// before
var member = (WpfKnownMember)context.GetXamlMember(prop, schemaCtx); // already frozen
member.IsReadPrivate = true; // throws
// after
class MyMember : XamlMember { protected override bool LookupIsReadPrivate() => true; }
var member = new MyMember(prop, schemaCtx);
Defensive patterns

Strategy: type-guard

Validate before calling

// Guard against mutating frozen known members
if (member is WpfKnownMember { Frozen: true })
    throw new InvalidOperationException("Known member is frozen; override via a custom XamlMember instead.");

Type guard

static bool IsMutableMember(System.Xaml.XamlMember m) => m is not WpfKnownMember { Frozen: true };

Try / catch

try
{
    ConfigureMember(knownMember);
}
catch (InvalidOperationException ex) when (ex.Message.Contains("Can't Assign to Known Member"))
{
    // wrap with a custom XamlMember overriding the desired lookup instead of mutating
    throw new NotSupportedException("Create a derived XamlMember with overridden Lookup* methods.", ex);
}

Prevention

When it happens

Trigger: Attempting to mutate a WpfKnownMember (e.g. setting a delegate or type-converter flag) after the WPF known-types table froze it — typically during or after schema lookup, or from custom XAML schema code touching cached members.

Common situations: Custom XamlSchemaContext / type-mapping code writing to known members at load time instead of during table construction; reflection-based tools trying to patch WPF member metadata; re-initializing shared schema members across AppDomain reloads.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14). Data as JSON: /api/errors/65073afdd9f84c39. Report an issue: GitHub.

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Markup/Baml2006/WpfKnownMember.cs:103

            _type = type;
            ReadOnly = isReadOnly;
        }

        protected override bool LookupIsUnknown()
        {
            return false;
        }

        public void Freeze()
        {
            Frozen = true;
        }

        private void CheckFrozen()
        {
            if (Frozen)
            {
                throw new InvalidOperationException("Can't Assign to Known Member attributes");
            }
        }

        protected override System.Xaml.Schema.XamlMemberInvoker LookupInvoker()
        {
            return new WpfKnownMemberInvoker(this);
        }

        public Action<object, object> SetDelegate
        {
            get
            {
                return _setDelegate;
            }
            set
            {
                CheckFrozen();
                _setDelegate = value;

View on GitHub (pinned to 81131a70a4)