Weird Control.Margin values when screen DPI is greater than 100%

[harborsiem]

.NET version

.NET8.0, .NET6.0

Did it work in .NET Framework?

Not tested/verified

Did it work in any of the earlier releases of .NET Core or .NET 5+?

No

Issue description

TestUpDown.zip
I have done a simple test project with NumericUpDown and Button controls.

1. Controls are placed direct to the Form.
2. Controls are placed on a TableLayoutPanel (Parent is the Form)
3. Controls are placed on a Panel (Parent is the Form)
4. Controls are placed on a Panel (Parent is an other Panel which is placed on the Form)

When pressing the Buttons one gets a MessageBox with information about DisplayRectangle and Margin values for the Button and NumericUpDown.
When you run with 100% screen DPI the Margin values are all set to 3. But when you run with a higher DPI the Margin values are weird. For example in test case 4 with DPI=150% I get NumericUpDown Margin values 9, 13, 9, 13 and for the Button I get 4, 5, 4, 5.

In the project I have set ApplicationHighDpiMode to PerMonitorV2. But it seems that the issue is also present in other DpiModes.

Steps to reproduce

Run the project with different DPI values and press the Buttons and notice the MessageBox values.
Form at 100% DPI

MessageBox with DPI=150% when pressing button4

[LeafShi1]

In our investigation, this issue is closely related to DPI scaling and the form's autoscaling baseline (AutoScaleDimensions).

At runtime, WinForms calculates the scaling factor using: CurrentAutoScaleDimensions / AutoScaleDimensions and applies autoscaling based on the resulting factor.

In our testing, when AutoScaleDimensions correctly reflects the DPI/font baseline used during design time, the unexpected Margin values can no longer be reproduced. This indicates that the reported behavior is likely related to autoscaling being applied on an incorrect scaling baseline rather than an error in the Margin implementation itself.

The larger discrepancies observed for certain controls (such as NumericUpDown) appear to be related to how autoscaling is applied through their control hierarchy and parent containers, resulting in scaling behavior that differs from simpler controls such as Button.

As a workaround:

1. Ensure the form's AutoScaleDimensions reflects the DPI/font baseline used during design time.
2. After correcting the autoscaling baseline, enable:
   <ForceDesignerDpiUnaware>true</ForceDesignerDpiUnaware>
   to prevent future DPI-dependent designer serialization changes.

Please refer to https://github.com/dotnet/winforms/blob/main/docs/designer/designer-high-dpi-mode.md