dotnet/wpf · error · XamlParseException
type-parse error string from XamlTypeName.ParseInternal…
Error message
type-parse error string from XamlTypeName.ParseInternal (e.g. SR.PrefixNotFound/InvalidTypeString)
What it means
MeScanner.ResolveTypeName resolves the bare type name inside curly markup-extension form (e.g. '{StaticResource ...}' where 'StaticResource' must resolve to 'StaticResourceExtension'). It calls XamlTypeName.ParseInternal; if that returns null (PrefixNotFound, InvalidTypeString, etc.), the stored error string is thrown as XamlParseException.
Solutions
- Verify the extension name is correct and the extension type exists
- Register the extension's assembly/namespace via xmlns declarations or XmlnsDefinition attributes
- Fix the type-string syntax inside the curly form
- Catch XamlParseException around scanner/parser use and inspect the inner error text
Example fix
// before
<TextBlock Text="{CustomxExtension Foo}"/> // unregistered name
// after
xmlns:ext="clr-namespace:MyApp.Extensions;assembly=MyApp"
<TextBlock Text="{ext:CustomExtension Foo}"/> Defensive patterns
Strategy: try-catch
Validate before calling
// verify the extension type resolves before curly-form scanning
bool ExtensionResolves(string name, XamlSchemaContext ctx)
{
var tn = XamlTypeName.Parse(name, ctx.FindNamespaceByPrefix, out _);
return tn != null && ctx.GetXamlType(tn, false) != null;
} Try / catch
try { scanner/readResult = ...; }
catch (XamlParseException ex) { /* ex.Message carries the underlying PrefixNotFound/InvalidTypeString text from ParseInternal */ } Prevention
- Register custom extension types with XmlnsDefinition
- Follow the 'NameExtension' naming convention for curly-form lookup
- Test third-party namespaces resolve before deployment
When it happens
Trigger: Using a markup extension whose name cannot be resolved: unknown/misspelled extension name, missing xmlns prefix mapping, or a syntactically invalid type-name portion of the curly string.
Common situations: Custom markup extensions not registered via XmlnsDefinition, typos in extension names, missing namespace declarations when consuming third-party XAML libraries.
Understand the failure class
Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.
- Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.
Related errors
- SR.Format(SR.MarkupExtensionTypeNameBad, _typeName)
- ArgumentNullException(nameof(arrayType))
- ArgumentNullException(nameof(localName))
- ArgumentNullException(nameof(member))
- ArgumentNullException(nameof(xmlNamespace))
AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14).
Data as JSON: /api/errors/308add91f562829e.
Report an issue: GitHub.
Appendix: source
Thrown at src/Microsoft.DotNet.Wpf/src/System.Xaml/System/Xaml/Parser/MeScanner.cs:293
builder.Append(value[idx + 1]);
}
// pick up again after that
start = idx + 2;
}
}
while (start < value.Length);
string result = builder.ToString();
return result;
}
private void ResolveTypeName(string longName)
{
string error;
XamlTypeName typeName = XamlTypeName.ParseInternal(longName, _context.FindNamespaceByPrefix, out error);
if (typeName is null)
{
throw new XamlParseException(this, error);
}
// In curly form, we search for TypeName + 'Extension' before TypeName
string bareTypeName = typeName.Name;
typeName.Name += KnownStrings.Extension;
XamlType xamlType = _context.GetXamlType(typeName, false);
// This would be cleaner if we moved the Extension fallback logic out of XSC
if (xamlType is null ||
// Guard against Extension getting added twice
(xamlType.UnderlyingType is not null &&
KS.Eq(xamlType.UnderlyingType.Name, typeName.Name + KnownStrings.Extension)))
{
typeName.Name = bareTypeName;
xamlType = _context.GetXamlType(typeName, true);
}
_tokenXamlType = xamlType;
_tokenNamespace = typeName.Namespace;View on GitHub (pinned to 81131a70a4)