winver) 17763.167Does the bug reproduce also in WPF for .NET Framework 4.8?: No
Problem description:
This writes a ResourceDictionary to disk, then I load it immediately. However… this causes the following exception:
System.Windows.Markup.XamlParseException: ''Cannot set unknown member 'System.Windows.ResourceDictionary.IsReadOnly'.' Line number '2' and line position '21'.'
Below is the resource dictionary generated by the XamlWriter:
<?xml version="1.0" encoding="utf-8"?>
<ResourceDictionary IsReadOnly="False" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Color x:Key="Fluent.Ribbon.Colors.AccentColor80">#CCD24726</Color>
<Color x:Key="Fluent.Ribbon.Brushes.AccentColorBrush60">#99D24726</Color>
….
</ResourceDictionary>
Actual behavior:
System.Windows.Markup.XamlParseException: ''Cannot set unknown member 'System.Windows.ResourceDictionary.IsReadOnly'.' Line number '2' and line position '21'.'
Expected behavior:
Successfully deserialized ResourceDictionary
Minimal repro:
using (var writer = XmlWriter.Create(fileName, new XmlWriterSettings
{
Indent = true,
IndentChars = " "
}))
{
XamlWriter.Save(resourceDictionary, writer);
writer.Flush();
}
resourceDictionary = new ResourceDictionary
{
Source = new Uri(fileName, UriKind.Absolute)
};
@GeertvanHorrik, It's not clear to me how you generate the file containing the ResourceDictionary xml that has the IsReadOnly="False" element in it. A self-contained application would be helpful here. Would you be able to share a repro solution that illustrates the problem?
Preferably, create an SDK netcoreapp3.0 WPF project, and set <TargetFrameworks>net472;netcoreapp3.0</TargetFrameworks> so we can see side-by-side what's happening.
See https://github.com/WildGums/Orchestra/blob/d6f340df9b7e178f36cdb3a078ed72825c75b0a0/src/Orchestra.Shell.Ribbon.Fluent/Helpers/FluentRibbonHelper.cs#L30 with a workaround.
You should be able to run the Fluent.Ribbon example with netcoreapp3.0. If you uncomment the workaround, you'll find the repro.
Thanks for the additional repro hint. The problem seems to be in the serialization step, and not at deserialization. I've created more detailed repro instructions in my fork, along with a side-by-side comparison of the generated/serialized XAML between net472 vs netcoreapp3.0.
@ryalanms, this looks like another instance of XAML serialization that differs between .NET Framework and .NET Core. In this case, the differences matter and seems serious (unlike the previous ones that we have seen, which were all benign). I think we need to get to the root of all the differences we have observed so far, and get a clear picture of why they are happening, and have a plan for minimizing these to unavoidable ones (for e.g., ones that arise due to unavoidable XML library differences between .NET Framework vs. .NET Core).
cc @dotnet/wpf-developers
@GeertvanHorrik, could you try with the most recent Preview 6 core SDK build (012258)? I was able to serialize a ResourceDictionary using the minimal repro, and the xml file output by XamlWrite no longer contains an additional 'IsReadOnly' property. After removing the '#if NETCORE' workaround from FluentRibbonHelper.cs, the most recent version of Orschestra.Examples.Ribbon.Fluent appeared to work correctly, and ApplicationOutputColors.xaml looked correct. There have been several fixes since December which may have affected this scenario. Thanks.
Fantastic, it works great! This build also fixes a few other issues (such as half-broken ellipses, etc):

Great work, please keep it up, it's much appreciated 👍
Most helpful comment
Thanks for the additional repro hint. The problem seems to be in the serialization step, and not at deserialization. I've created more detailed repro instructions in my fork, along with a side-by-side comparison of the generated/serialized XAML between net472 vs netcoreapp3.0.
@ryalanms, this looks like another instance of XAML serialization that differs between .NET Framework and .NET Core. In this case, the differences matter and seems serious (unlike the previous ones that we have seen, which were all benign). I think we need to get to the root of all the differences we have observed so far, and get a clear picture of why they are happening, and have a plan for minimizing these to unavoidable ones (for e.g., ones that arise due to unavoidable XML library differences between .NET Framework vs. .NET Core).
cc @dotnet/wpf-developers