System.Type as Property of Converter in UWP – unexplainable XamlParseException

Two weeks ago in a project we had a XamlParseException when a special page was opened. Strange thing was, that we didn’t change anything of the XAML- Code, since the last working version. There were only some small changes in the code-behind of the page.

The error message was following: Windows.UI.Xaml.Markup.XamlParseException: ‘The text associated with this error code could not be found. Failed to create a ‘UWPSystemTypeConverterTest.Converter.EnumTypeConverter’ from the text ‘enums:CustomEnum’. [Line: 14 Position: 56]’

Here is the code that produces this error. Complete project can be found on

shortened XAML Page:

        <converter:EnumTypeConverter x:Key="Converter" TypeToDisplay="enums:CustomEnum" />
    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
        <TextBlock Text="{Binding Converter={StaticResource Converter}}" />


internal class EnumTypeConverter : IValueConverter
    public Type TypeToDisplay { get; set; }
    public object Convert(object value, Type targetType, object parameter, string language)
        return TypeToDisplay?.FullName;
    public object ConvertBack(object value, Type targetType, object parameter, string language)
        throw new NotImplementedException();

The interesting thing was, when we added a public property of the enum to the code-behind of the XAML page, it worked.

Code- Behind:

public sealed partial class MainPage : Page
        public CustomEnum WithThisPropertyTheAppWorks { get; set; }
        public MainPage()
            this.DataContext = this;

Reason why it worked: After a StackOverflow post and some mails on a MVP mailing lists, I got an answer for the strange behaviour. The XAML compiler and the runtime don’t support System.Type- typed properties. So the needed metadata is not generated and the runtime can not convert the string to the type.

But because of the public properties on the code-behind, the compiler generates the needed metadata now. I am not that happy with the work around, but it is better than other solutions (e.g. a string property with the fullname to the type).

I hope that in a future version of the UWP Xaml Compiler and runtime this will be addressed and will be no more issue. But up to now, you know how to fix the error if you encounter it.