dotnet/wpf · error · InvalidOperationException
SR.MustNotCallSetter
Error message
SR.MustNotCallSetter
What it means
XaslMember (a legacy internal XAML member type) declares `new public XamlType DeclaringType` whose setter unconditionally throws InvalidOperationException('MustNotCallSetter'). The property is read-only in spirit — declaring type is fixed at construction — and mutating it through the shadowing setter is explicitly disallowed by the base-member contract.
Solutions
- Set the declaring type at construction time (constructor argument) rather than via the property.
- Remove the mutation — a member's declaring type is fixed identity; create a new XaslMember bound to the correct type instead.
- Catch InvalidOperationException if assignment comes from generic property-setting code and skip that property.
Example fix
// before member.DeclaringType = newType; // after var rebuilt = new XaslMember(member.Name, newType);
Defensive patterns
Strategy: try-catch
Validate before calling
// DeclaringType has no usable setter; never assign it.
bool isMutable = typeof(XamlMember).GetProperty("DeclaringType")!.CanWrite; // false by design Type guard
static bool CanSetDeclaringType(object m) => m is not XaslMember;
Try / catch
try { prop.SetValue(member, newType); } catch (InvalidOperationException) { /* read-only member property */ } Prevention
- Treat DeclaringType as immutable on all XamlMember implementations.
- Create a new member instance bound to the correct declaring type instead of mutating.
- Skip DeclaringType in generic property-copy/serialization loops.
- Update code still targeting the legacy Xasl API to the standard XamlMember.
When it happens
Trigger: Assigning to DeclaringType on a XaslMember instance, e.g. myXaslMember.DeclaringType = someXamlType; — typically code written against the base XamlMember API surface that assumes the setter exists and works.
Common situations: Migration or tooling code that re-parents members between types at runtime; generic reflection/serialization code that sets properties via PropertyInfo.SetValue; porting older code that used a mutable DeclaringType on a different member implementation.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
- Microsoft.Windows.Controls.SR.Ribbon_ContextualTabHeadersSou…
- SR.ExpandPositionalParametersWithReadOnlyProperties
- SR.MustNotCallSetter
- SR.OnlySupportedOnCollectionsAndDictionaries
- SR.OnlySupportedOnDictionaries
AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14).
Data as JSON: /api/errors/e1fdcf2186c50f2e.
Report an issue: GitHub.
Appendix: source
Thrown at src/Microsoft.DotNet.Wpf/src/System.Xaml/System/Xaml/Schema/XaslMember.cs:73
[DefaultValue(true)]
new public bool IsBrowsable
{
get { return IsBrowsableCore; }
set { IsBrowsableCore = value; }
}
[DefaultValue(false)]
new public bool IsObsolete
{
get { return IsObsoleteCore; }
set { IsObsoleteCore = value; }
}
new public XamlType DeclaringType
{
get { return DeclaringTypeCore; }
set { throw new InvalidOperationException(SR.MustNotCallSetter); }
}
// Should the default be "x:String"?
// We don't currently have a type converter to support: <XaslProperty Name="blah" Type="x:String" />
[TypeConverter(typeof(XaslTypeReferenceConverter))]
new public XamlType Type
{
get { return TypeCore; }
set { TypeCore = value; }
}
[DefaultValue(null)]
new public XamlTextSyntax TextSyntax
{
get { return TextSyntaxCore; }
set { TextSyntaxCore = value; }
}
View on GitHub (pinned to 81131a70a4)