-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Removing or annotating Serializable attribute on winforms classes #1425
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍
Few minor comments
src/System.Windows.Forms.Design/src/System/ComponentModel/Design/ExceptionCollection.cs
Outdated
Show resolved
Hide resolved
...esign/src/System/ComponentModel/Design/Serialization/CodeDomComponentSerializationService.cs
Outdated
Show resolved
Hide resolved
src/System.Windows.Forms/src/System/Windows/Forms/ListViewItem.cs
Outdated
Show resolved
Hide resolved
b0b8739
to
1e4647f
Compare
src/System.Windows.Forms.Design/src/System/ComponentModel/Design/ExceptionCollection.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pending more tests, LGTM
1e4647f
to
3882bbf
Compare
46f1f71
to
c2ef8e4
Compare
Codecov Report
@@ Coverage Diff @@
## master #1425 +/- ##
===================================================
+ Coverage 25.64901% 25.76099% +0.11198%
===================================================
Files 786 786
Lines 268256 268169 -87
Branches 37978 37968 -10
===================================================
+ Hits 68805 69083 +278
+ Misses 194557 194164 -393
- Partials 4894 4922 +28
|
src/System.Windows.Forms/tests/UnitTests/SerializableTypesTests.cs
Outdated
Show resolved
Hide resolved
LGTM but you should investigate this test failure. Looks like something in the debug skew for |
{ | ||
public static class BinarySerialization | ||
{ | ||
public static void EnsureSerializableAttribute(Assembly assemblyUnderTest, Dictionary<string, bool> serializableTypes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than test by checking for attribute, just ensure you have a test-case that actually serializes every type. Could be useful for a negative case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't too bad after further consideration, just make sure you have actual test cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I simplified these tests to focus on blocking addition of serializable types.
{ | ||
public static class BinarySerialization | ||
{ | ||
public static void EnsureSerializableAttribute(Assembly assemblyUnderTest, Dictionary<string, bool> serializableTypes) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't too bad after further consideration, just make sure you have actual test cases.
public sealed class ExceptionCollection : Exception | ||
{ | ||
private readonly ArrayList _exceptions; | ||
private const string SerializationKey = "exceptions"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than introducing a constant here, consider reverting the field name to exceptions
then using nameof(exceptions)
in the constructor / GetObjectData. Also consider adding // Do not rename (binary serialization)
. It'll be helpful if you express the serialization constraint consistently across the repo so that its easier for code-reviewers to catch the cases where folks may introduce new fields, or rename, and break serialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change is not as uniform as I had hoped because usually we have custom serialization code and do not serialize private fields, but rather pre-process data that we want to serialize or serialize public properties, Or serialize public property under a different name - for example Tag
property is serialized as UserData
.
I applied your suggestion only in cases where we are serializing private properties.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Well one benefit of always having custom implementations of these methods is that its much harder to break compatibility accidentally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, the compatibility goal is achieved, but the source is not "intuitive" - it's impossible to deduce type members from the serialized data. But this is not the goal of this work item.
c2ef8e4
to
e365d35
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few little nits.
One question whether it is worth adding tests to check there are serialisable types other than those that we expect.
src/System.Windows.Forms.Design.Editors/tests/UnitTests/SerializableAttributeTest.cs
Show resolved
Hide resolved
src/System.Windows.Forms.Design/src/System/ComponentModel/Design/ExceptionCollection.cs
Outdated
Show resolved
Hide resolved
src/System.Windows.Forms.Design/tests/UnitTests/SerializableAttributeTests.cs
Show resolved
Hide resolved
src/System.Windows.Forms/tests/IntegrationTests/WinformsControlsTest/TreeViewTest.Designer.cs
Show resolved
Hide resolved
Btw happy to have it merged as-is to take it into P8, we can do further tweaks as a follow up. |
e365d35
to
52881e1
Compare
...ystem.Windows.Forms.Design/tests/UnitTests/System/ComponentModel/Design/DesignerHostTests.cs
Outdated
Show resolved
Hide resolved
@RussKie - thanks! I would like to remove this attribute from 3 more types, need to double check that I am not missing some scenarios . And then will send to Olina for testing. Thus I made this [WIP] again |
52881e1
to
2ad76d1
Compare
This comment has been minimized.
This comment has been minimized.
@ericstj - we don't have any serializable types in S.W.F.Editors. In System.Windows.Forms.Design we have a single serializable type (CodeDomSerializationStore) This type is used in Copy/Paste scenarios in VisualStudio. We are likely to use BinarySerialization on this type in the CoreDesigner as well, but we don't anticipate scenarios where we exchange types between the Core and .Net. Primarily because even if we are able to deserialize property store and type information of a control from one FX on another FX, we will not be able to discover the "destination" framework assembly. This type will be used to copy/paste controls between 2 Core containers only. |
@ViktorHofer - thank you for the review, here is the issue #1549 |
95800f6
to
2872a34
Compare
67396e1
to
5b03e70
Compare
…y serialization scenarios and annotates fields of types that still participate inbinary serialization
5b03e70
to
0fb5f8b
Compare
docs - dotnet/docs#14175 |
@Tanya-Solyanik reviewing #1237 I spotted that we still have serialisation-related decorations and logic in ResXFileRef: Should |
yes, thank you, good point! removed here: #1921 |
Fixes #889
Fixes #890
Fixes #1251
Proposed changes
Removed SerializableAttribute from types that don't have known binary serialization scenarios and annotated types that are staying serializable.
Lists of types are in #889
Customer Impact
This change reduces security risk associated with binary serialization
Regression?
no
Risk
high - might have to add attributes again if legitimate serialization scenarios exist
Test methodology
Manual verification and additional testing of resx serialization
Microsoft Reviewers: Open in CodeFlow