Inconsistency in Persistence of Property Values with DesignerSerializationVisibility between .NET Framework and .NET Core.

[RajClinton26]

Bug Description

When utilizing a property with DesignerSerializationVisibility set to 'Content', an inconsistency has been observed between the behavior of .NET Framework and .NET Core. Specifically, after assigning a value to this property in the designer, the assigned value persists after rebuilding in .NET Framework, but not in .NET Core.

Could you please suggest a solution to ensure consistent behavior of DesignerSerializationVisibility between .NET Framework and .NET Core?

Replication Procedure:

Build the both .NET Framework and .NET core sample successfully. In designer Right-click the control and select "Properties" from the context menu. Assign a value to the CanChangeValue property in the designer. Rebuild the solution. Check if the assigned value to the CanChangeValue property persists after rebuilding the solution.

Observed Behavior

After rebuilding the project, the assigned value to the property in the designer persists in .NET Framework but not in .NET Core.

Expected Behavior:

The assigned value to the property in the designer should persist after rebuilding the project in both .NET Framework and .NET Core.

Sample

Framework Sample CCFramework.zip Core Sample CustomControl.zip

Screenshots

In Framework

https://github.com/dotnet/winforms/assets/153497176/47324514-cfd9-42e6-9902-5989351b3ca0

In Core

https://github.com/dotnet/winforms/assets/153497176/b249e2d0-852e-465c-a30a-758d053f693a

Environment

Operating System: Windows 11 .NET Framework version: 4.6.2 .NET Core version: 6.0 IDE : Visual Studio professional 2022 (17.9.6)

[merriemcgaw]

@LeafShi1 can you guys pull out the list of types or properties in the sample project so we know which one's we're worrying about.

[Epica3055]

        [DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]
        public bool CanChangeValue
        {
            get;
            set;
        }

[SathiyathanamSathish]

Hi @merriemcgaw / @LeafShi1 / @Epica3055 ,

Any update regarding the above designer related issues in .NET Core.?

[elachlan]

@RajClinton26 why are you using DesignerSerializationVisibility.Content on a bool property? Shouldn't you use DesignerSerializationVisibility.Visible?

DesignerSerializationVisibility.Content is for more complex objects like Collections, is that what you are having issues with?

@Epica3055 Can your team test that DesignerSerializationVisibility.Visible works okay on the same property?

[RajClinton26]

@elachlan I have used the DesignerSerializationVisibility.Visible attribute on a property, and it worked fine.

However, when we used the DesignerSerializationVisibility.Content attribute on a non-complex object property, the assigned value to this property persists after rebuilding in .NET Framework, but not in .NET Core.

Could you please provide the reason for this inconsistency?

[elachlan]

I have no idea, but at least there is a work around for now.

When you say non-complex object property do you mean a class or a primitive? DesignerSerializationVisibility.Content is really meant for collections and not much else. I suspect its the designer not checking the object type, or maybe it needs a custom TypeConverter for your class?

It is definitely a bug for a bool property to not be persisted when using DesignerSerializationVisibility.Content in my mind, the designer should handle that. Otherwise an analyzer should exist for DesignerSerializationVisibility.Content and warn users about using it on primitive properties.

[SathiyathanamSathish]

@elachlan - Thanks for the update. Can we consider this as a bug in .NET CORE.?

[elachlan]

Up to the team. I do not work on the winforms team. I suggest using DesignerSerializationVisibility.Visible as a work around until it is fixed.

[merriemcgaw]

We will take a look at this, but be aware that since a simple workaround exists this issue won't be high in the priority list.

[KlausLoeffelmann]

I do not think it is a bug, but by design. The notion that you have a custom designer may indicate in the real-world-solution, that there is a more complex ControlDesigner invoked, which probably isn't invoked in .NET core.

I would need a complete repro with a complex object and the respective Designer to assess this.

Please make sure, for migrating a ControlDesigner to .NET Core, you are taking this into account:

https://devblogs.microsoft.com/dotnet/custom-controls-for-winforms-out-of-process-designer/

Closing this for now as non-repro. Feel free to reopen!