dotnet/wpf · error · InvalidOperationException

SR.Format(SR.StyleTargetTypeMismatchWithElement…

Error message

SR.Format(SR.StyleTargetTypeMismatchWithElement, this.TargetType.Name, elementType.Name)

What it means

CheckTargetType verifies that the TargetType declared on a Style is assignable from the type of the element the style is being applied to. When an element whose type is not derived from TargetType receives this style, InvalidOperationException is thrown with both type names.

Solutions

Change the style's TargetType to the element's type or one of its base types.
Apply the style only to elements assignable to TargetType.
Use a common base type (e.g. Control or FrameworkElement) as TargetType when one style should serve multiple control types, adjusting Setter properties accordingly.

Example fix

// before
var style = new Style(typeof(Button));
checkBox.Style = style; // throws
// after
var style = new Style(typeof(CheckBox));
checkBox.Style = style;

Defensive patterns

Strategy: validation

Validate before calling

if (element != null && style.TargetType != null && !style.TargetType.IsAssignableFrom(element.GetType()))
    throw new InvalidOperationException($"Style targets {style.TargetType.Name}, element is {element.GetType().Name}");
element.Style = style;

Type guard

static bool StyleFitsElement(Style s, FrameworkElement e) => s?.TargetType?.IsAssignableFrom(e.GetType()) ?? true;

Try / catch

try { element.Style = style; }
catch (InvalidOperationException ex) { log.Error("TargetType mismatch", ex); }

Prevention

Check TargetType matches (or is a base of) the element type before assigning Style.
When sharing styles across controls, key off a common base type.
Avoid copy-pasting styles without updating TargetType.

When it happens

Trigger: Setting element.Style (or an implicit style lookup) to a Style whose TargetType (e.g. Button) does not match or is not a base class of the element's actual type (e.g. CheckBox element receiving a Button-targeted style).

Common situations: Copy-pasting styles between controls without changing TargetType; sharing a ResourceDictionary across projects where control types differ; applying an implicit-style keyed resource to a differently-typed element via Style="{StaticResource ...}".

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors

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

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Style.cs:469

                    Property = dp,
                    ValueInternal = value
                };

                PropertyValues.Add(propertyValue);
            }
        }

        internal void CheckTargetType(object element)
        {
            // In the most common case TargetType is Default
            // and we can avoid a call to IsAssignableFrom() who's performance is unknown.
            if(DefaultTargetType == TargetType)
                return;

            Type elementType = element.GetType();
            if(!TargetType.IsAssignableFrom(elementType))
            {
                throw new InvalidOperationException(SR.Format(SR.StyleTargetTypeMismatchWithElement,
                                                    this.TargetType.Name,
                                                    elementType.Name));
            }
        }

        /// <summary>
        /// This Style and all factories/triggers are now immutable
        /// </summary>
        public void Seal()
        {
            // Verify Context Access
            VerifyAccess();

            // 99% case - Style is already sealed.
            if (_sealed)
            {
                return;
            }

View on GitHub (pinned to 81131a70a4)