dotnet/wpf · error · InvalidOperationException

Can't Assign to Known Type attributes

Error message

Can't Assign to Known Type attributes

What it means

WpfKnownType caches BAML-known type metadata (attributes, content property names, converters) and is frozen once the shared schema context is fully initialized. CheckFrozen guards any late mutation of that metadata. This InvalidOperationException means code attempted to assign a known-type attribute after the type was frozen, which the library treats as an internal invariant violation rather than a user error.

Solutions

  1. Populate all known-type attributes before the schema context freezes its tables (during construction/initialization), not lazily afterward.
  2. If you subclass WpfKnownType, compute values in overridden Lookup* methods instead of assigning frozen properties.
  3. Check the Frozen property before assigning and skip/warn instead of mutating.
  4. Verify no thread race: freeze on one thread only after all initialization completes.

Example fix

// before
knownType.ContentPropertyName = "Children"; // after context is frozen
// after
var knownType = new WpfKnownType(..., contentPropertyName: "Children", ...); // set at construction, before freezing
Defensive patterns

Strategy: validation

Validate before calling

if (knownType.Frozen)
    throw new InvalidOperationException("Known type is frozen; set attributes during initialization.");

Type guard

bool CanMutate(WpfKnownType t) => !t.Frozen;

Prevention

When it happens

Trigger: Setting BamlNumber, ContentPropertyName, RuntimeNamePropertyName, XmlLangPropertyName, UsableDuringInitialization, or a value converter on a WpfKnownType after Frozen became true — i.e. mutating known-type metadata outside schema-context initialization (typically only from custom subclasses of WpfKnownType or reflection hacks).

Common situations: Custom Baml2006 schema-context/known-type subclasses that populate attributes lazily after the context sealed its tables; reflective tooling or tests that mutate known types post-initialization; concurrency bugs where a thread assigns metadata after another thread froze it.

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/504155dfd1ef9939. Report an issue: GitHub.

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Markup/Baml2006/WpfKnownType.cs:93

            bool isBamlType,
            bool useV3Rules)
            : base(underlyingType, schema, isBamlType, useV3Rules)
        {
            _bamlNumber = (short)bamlNumber;
            _name = name;
            _underlyingType = underlyingType;
        }

        public void Freeze()
        {
            Frozen = true;
        }

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

        public short BamlNumber
        {
            get { return _bamlNumber; }
        }

        protected override XamlMember LookupContentProperty()
        {
            return CallGetMember(_contentPropertyName);
        }

        public string ContentPropertyName
        {
            get { return _contentPropertyName; }
            set
            {

View on GitHub (pinned to 81131a70a4)