Hello team!

My name is Dmitrii, and I am writing on behalf of the DevExpress WinForms Team.

First, thank you for your tremendous effort in advancing the .NET platform and, especially, in improving the security and maintainability of .NET applications.

As stated in the documentation, the WFO1000 security analyzer aims to enhance the security and maintainability of Windows Forms apps by enforcing proper serialization practices, thereby reducing the risk of accidental data exposure.

However, in some cases, it flags certain members that cannot be used for serialization, which can be considered false positives.

The affected cases include:

1. Private properties of components that do not have the InitializeComponent method:

public class CustomControl1 : Control {
    // This property's value can't be used for serialization but is flagged by WFO1000
    public string? Value1 {  get; private set; }
    // This property's value can't be used for serialization but is flagged by WFO1000
    public string? Value2 {  get; internal set; }
}

2. Both private and public static properties of components:

public class CustomControl2 : Control {
    // This property's value can't be used for serialization but is flagged by WFO1000
    public staic string? Value1 { get; set; }
    // This property's value can't be used for serialization but is flagged by WFO1000
    public staic string? Value2 { get; private set; }
}

3. Both private and public overridden properties of standard controls descendants that are already configured for serialization at the base-component level:

public class CustomControl3 : Control {
    // This property has a ShouldSerializeCursor method at the Control type level,
    // and this ShouldSerializeCursor method is actually used during serialization
    public override Cursor Cursor {
        get => base.Cursor;
        set => base.Cursor = value;
    }
}

To reproduce these issues, you can create a new .NET 9 WinForms application and insert the code samples above.

Previous Behavior

Previously, for the cases mentioned above, properties of custom Windows Forms controls could be used without explicit serialization configuration (because no configuration was needed in those cases). The analyzers did not produce warnings.

Current Behavior

The analyzers now produce warnings such as:

WFO1000: Property 'property' does not configure serialization for its property content.

Impact

The impact of this change can be substantial. For example, in our case as a control vendor, thousands of flagged points appear in our codebase, many of which are false positives - we have numerous internal components and control's parts that are can not be publicly used, and we are 100% certain they are not involved in design-time serialization processes. But we fully understand the underlying reasons for this analyzer and appreciate their importance, so we are addressed all of these flagged points at our side.

Our primary goal with this bug report is to advocate for a refinement of this analyzer's behavior to mitigate any negative effects and to help developers transition to more secure serialization practices without compromising their productivity or project stability. However, the excessive false positives generated by the WFO1000 analyzer can affect thousands of developers worldwide, particularly those managing large, complex Windows Forms projects. For teams with the WarningsAsErrors option enabled, the inability to compile due to false-positive warnings significantly disrupts development workflows and productivity.

Please feel free to reach out if additional information or specific examples from our codebase would be helpful in refining the analyzer’s behavior. We’re eager to collaborate and provide feedback to ensure this analyzer supports a smoother transition for developers worldwide.

Kind regards,
Dmitrii
DevExpress WinForms Team