Break Issue in Net9.0 for RadioButton used in a PopUp

[umanagarajan12]

Description

We have updated all our projects to support .NET 9.0. As previously noted, our projects use a custom theme that functions well in .NET 8.0 and other frameworks but has been causing issues specifically in .NET 9.0.

We have logged this issue #10020 and received the recommendation: "The issue is due to a recent change to optimize DynamicResource usage (#5610). To prevent the crash, you can opt-out of this behavior by adding the following to your .csproj file:

<ItemGroup>
    <RuntimeHostConfigurationOption Include="Switch.System.Windows.Controls.DisableDynamicResourceOptimization" Value="true" />
</ItemGroup>

This solution has resolved the issue in some sample projects. However, we still encounter problems in other cases when using themes:

In our DataGrid control, we use RadioButtons in the filter functionality, but we are encountering issues when clearing filters.

Steps to Reproduce:

1. Open the Filter Popup and apply a filter using the Advanced Filter options (e.g., Text Filter or Numeric Filter).
2. Use the first filter option to apply a filter.
3. Select the "And" option, which deselects the default "Or" option.
4. Click the OK button to apply the filter.
5. Reopen the Filter Popup and click Clear Filter.

Expected Behavior:

• The "And" option should be deselected, and only the "Or" option should remain selected by default.

Actual Behavior:

• Both "And" and "Or" options remain selected simultaneously, which is incorrect.

Expected Behavior Screenshot(Net 80):

Actual Behavior Screenshot(Net 90):

Note: We have also included <RuntimeHostConfigurationOption Include="Switch.System.Windows.Controls.DisableDynamicResourceOptimization" Value="true" /> in the .NET 9.0 project ItemGroup.

We’ve attached sample projects demonstrating this issue and video references for Issue replication.

Could you please investigate further?
Samples.zip
Video References.zip

[harshit7962]

@umanagarajan12 the issue is an unintended side-effect of the change introduced here. The changes were aimed to fix the issue described here.

As it seems, the use case above is a valid (and more common) one, and hence we have decided to revert the original change as of now and look for an alternate solution for the former issue.

We will keep the channel updated on the timelines of the fix. Thanks for bringing this to our notice.