System.ComponentModel.Design.Serialization.SerializationStore.Save(Stream stream) can not suppport .NET8

[icemaple1251]

Environment

OS: Microsoft Windows Version 22H2 (OS Build 19045.3570) VisualStudio 2022: Version 17.8.2

.NET version

.NET SDK:Version 8.0.100 Arch: X64(also can reproduce in other Arch)

Did this work in a previous version of Visual Studio and/or previous .NET release?

The serialization works well in .NET Framework 4.8 A sample project is provided.

Issue description

System.ComponentModel.Design.Serialization.SerializationStore.Save(Stream stream);

https://learn.microsoft.com/en-us/dotnet/api/system.componentmodel.design.serialization.serializationstore?view=net-7.0

The serialization works well in .NET Framework 4.8, but it shows 'platform not support' exception after we update to .NET8 SDK.

Steps to reproduce

Call System.ComponentModel.Design.Serialization.SerializationStore.Save(Stream stream) function directly to save a user control in .NET8 WinFormsNET8.zip

Diagnostics

We notice that, this function is support in .NET8 according to MSDN, but it throw 'platform not support' exception' when we call it.

> https://learn.microsoft.com/zh-cn/dotnet/api/system.componentmodel.design.serialization.serializationstore?view=net-8.0

[lonitra]

Looks like this was removed in https://github.com/dotnet/winforms/commit/44b5076b843a67ab8497fe73c17576ef3e4dbd99 but this was never fully ported.

[merriemcgaw]

Let's get this added to the runtime.

[merriemcgaw]

@LeafShi1 is this something your team can pick up - porting the .NET Framework code to the .NET 9 runtime? @lonitra can help answer questions.

cc: @Tanya-Solyanik FYI

[SimonZhao888]

Hi @Tanya-Solyanik ,

Which way should we choose to fix this issue? Revert the related changes or delete the public method which only used to throw PlatformNotSupportedException?

[Tanya-Solyanik]

@SimonZhao888 - please restore support for BinaryFormatter in the designer-related classes that was removed in https://github.com/dotnet/winforms/commit/44b5076b843a67ab8497fe73c17576ef3e4dbd99#diff-dc4b46b82fb9ffb51dde3794d0d877e9a09d93dd7f4cc0b8644c3ae22de5b610. Re-add the SerializableAttribute and re-add the required serialization constructors or ISerializable implementation. Then compare that code to the corresponding code in the VS repo, System.Design.dll sources to make sure all required code is ported. Classes to restore serialization in:

1. ExceptionCollection
2. CodeDomSerializationStore
3. CodeDomSerializerException

[Tanya-Solyanik]

CodeDomSerializationService serializes arbitrary objects into a CodeDomSerilizationStore type that contains collections of CodeDOM statements, to store objects that have CodeDOM serializers, and collection of objects to store resources (objects that don't have code DOM serializers). In .NET Framework, CodeDomSerilizationStore supported serialization to a stream - and Deserialization from a stream.

These APIs were implemented using BinaryFormater. To enable these scenarios in .NET, we must be able to binary serialize the CodeDomSerializationStore class. This class, however, references types that winforms team does not own, that are not binary-serializable in .NET, but were decorated with [Serializable] attribute in .NET Framework.

1. AssemblyName
2. CultureInfo
3. All System.CodeDOM classes (content of CodeStatementCollection), including CodeObject.UserData collection of arbitrary objects. UserData is controlled by the serialization manager, which can be supplied by the application author.
4. Collection of arbitrary objects that are serialized to resources by the user-provided serialization manager.

AssemblyName and CultureInfo could be replaced by their string representations for serialization purposes, however the lack of support for binary serialization for the other cases is preventing us from enabling this scenario.

Given our ongoing effort to replace BinaryFomatter with safer serializers, I suggest keeping PlatformNotSupported exceptions at the entry points of these scenarios, constructors, Save and LoadStore, and updating documentation for .NET to reflect that.

[merriemcgaw]

We need to document this and get the issue documented in the docs repo and then close this issue.

[Tanya-Solyanik]

Doc issue - https://github.com/dotnet/docs/issues/40440