ArgumentNullException when retrieving the default value of an Enum property defined with an integer

[icom85]

It is related to the DefaultValueAttribute, the Enums and the PropertyDescriptor class. The issue is in the static Enum.ToObject method. In order to observe the issue, it is necessary to use an integer as a default value of an enumeration. The code below easily reproduces it:

using System.ComponentModel;
using System.Windows.Forms;

namespace EnumDefaultValueIssue
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();

            var btn = new MyButton();
            var properties = TypeDescriptor.GetProperties(btn);
            var prop = properties["Dock"];

            // Crashes when calling ShouldSerializeValue on the PropertyDescriptor
            var shouldSerialize = prop.ShouldSerializeValue(btn);
        }
    }

    public class MyButton
    {
        //[DefaultValueAttribute(DockStyle.None)] //No crash
        [DefaultValueAttribute(0)] // Crash
        public DockStyle Dock { get;  set; }
    }
}

I`ve tested with the latest .NET 5.0 - 5.0.100-preview.8.20417.9, the issue is likely to be observed with other .NET Core runtimes. The same setup is working well in the full .NET framework.

Workaround:
Don't use the underlying integer type in the DefaultValueAttribute but rather the real enum member.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @safern
See info in area-owners.md if you want to be subscribed.

[joperezr]

Moving to ComponentModel given the issue seems to be with the way that ReflectPropertyDescriptor is trying to get the default value of the object. This is not a regression, as I can at least repro with 3.1

[safern]

Marking as 6.0.0 since it is not a regression. However I might be able to fix this while nullable annotating TypeConverters.

[safern]

This was fixed in: #55793