Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
RajClinton26 opened this issue Apr 24, 2024 · 9 comments
Assignees
Labels
area-VSDesigner Windows Forms out-of-proc designer related issues tenet-compatibility Incompatibility with previous versions or with WinForms for .NET Framework
Milestone

Comments

@RajClinton26
Copy link

RajClinton26 commented Apr 24, 2024

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

In.Framework.mp4

In Core

In.Core.mp4

Environment

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

@RajClinton26 RajClinton26 added the untriaged The team needs to look at this issue in the next triage label Apr 24, 2024
@merriemcgaw
Copy link
Member

@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
Copy link
Member

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

@LeafShi1 LeafShi1 removed their assignment Apr 25, 2024
@SathiyathanamSathish
Copy link

Hi @merriemcgaw / @LeafShi1 / @Epica3055 ,

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

@elachlan
Copy link
Contributor

@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?

@merriemcgaw merriemcgaw added untriaged The team needs to look at this issue in the next triage and removed untriaged The team needs to look at this issue in the next triage labels Apr 30, 2024
@elachlan elachlan added the 📭 waiting-author-feedback The team requires more information from the author label May 1, 2024
@RajClinton26
Copy link
Author

@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?

@dotnet-policy-service dotnet-policy-service bot removed the 📭 waiting-author-feedback The team requires more information from the author label May 2, 2024
@elachlan elachlan added tenet-compatibility Incompatibility with previous versions or with WinForms for .NET Framework area-VSDesigner Windows Forms out-of-proc designer related issues labels May 2, 2024
@elachlan
Copy link
Contributor

elachlan commented May 2, 2024

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
Copy link

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

@elachlan
Copy link
Contributor

elachlan commented May 2, 2024

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 merriemcgaw removed the untriaged The team needs to look at this issue in the next triage label May 15, 2024
@merriemcgaw
Copy link
Member

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.

@merriemcgaw merriemcgaw added this to the Future milestone May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-VSDesigner Windows Forms out-of-proc designer related issues tenet-compatibility Incompatibility with previous versions or with WinForms for .NET Framework
Projects
None yet
Development

No branches or pull requests

7 participants