Fix S3925 FP: BinaryFormatter serialization is deprecated, should be handled differently for >= .NET 8

[gregory-paidis-sonarsource]

This is a remainder from preparing for the .NET8 release.
Microsoft has been gradually dropping support for the BinaryFormatter, so the best practises referenced in this rule are different post-NET8.

Initially raised on this community post by Corniel.

See more discussion here (internal click)

S3925 Needs specification.

Relevant information:

• https://learn.microsoft.com/en-us/dotnet/core/compatibility/serialization/5.0/binaryformatter-serialization-obsolete
• https://github.com/dotnet/designs/blob/main/accepted/2020/better-obsoletion/binaryformatter-obsoletion.md
• https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/serialization#supporting-runtime-serialization

Expected behaviour of the rule:

• Only raise issues when the user explicitly opts-in for serialization of the concrete type by either (see also RSpec)
  • Applying the [Serializable] attribute
  • Having ISerializable in the base type list (it is explicitly mentioned in the current types base type list)
  • Declaring a serialization constructor
• If the user opts-in for serialization, the old rules apply without modification. The new .Net warnings need to be dealt with by the user as described by Microsoft.

[martin-strecker-sonarsource]

Other rules affected:

• S3925 - "ISerializable" should be implemented correctly
• S2552 - "Serializable" classes should provide a serialization constructor ✅ Rule not implemented
• S3927 - Serialization event handlers should be implemented correctly ✅ Only triggered on explicit formatting methods
• S5773 - Types allowed to be deserialized should be restricted ✅ Only triggered on explicit formatting methods
• S4027 - Exceptions should provide standard constructors Fix S4027 FP: BinaryFormatter. Serialization constructors are obsolete and should not be required #8560
• S3926 - Deserialization methods should be provided for "OptionalField" members ✅ Only triggered on explicit formatting methods
• S5135 - Deserialization should not be vulnerable to injection attacks ✅ Only triggered on explicit formatting methods
• S5766 - Deserializing objects without performing data validation is security-sensitive
• S1144 - Unused private types or members should be removed
• S4212 - Serialization constructors should be secured
• Fulltext RSpec search for "serializable"

A list of types/members annotated as deprecated can be found here:
https://github.com/dotnet/designs/blob/main/accepted/2020/better-obsoletion/binaryformatter-obsoletion.md#new-obsoletions-in-net-8

[Corniel]

@andrei-epure-sonarsource officially, this is not C#12 but .NET 8 related.

[DominikAmon]

Especially when writing custom exceptions that derive from System.Exception.
As System.Exception is still implements System.Runtime.Serialization.ISerializable SonarQube "forces" derived classes to implement the Serialization as well. This is where Roslyn kicks in with SYSLIB0051 - This API supports obsolete formatter-based serialization.

[martin-strecker-sonarsource]

The current implementation of S3925 requires the user to opt-in for serialization on the concrete type:

sonar-dotnet/analyzers/tests/SonarAnalyzer.Test/TestCases/ImplementISerializableCorrectly.cs

Lines 256 to 257 in 6d42fec

	public class MyException : Exception // Compliant: no opt-in for custom serialization
	{ }

sonar-dotnet/analyzers/tests/SonarAnalyzer.Test/TestCases/ImplementISerializableCorrectly.cs

Line 266 in 6d42fec

public class CustomLookup : Dictionary<string, object> // Compliant: no opt-in for custom serialization

If the user opts-in, he needs to follow the old guidelines. This rule already behaves as described in the issue description and the RSpec already mentions the opt-in behavior. There is nothing to change for this rule at the moment.

[pavel-mikula-sonarsource]

S4212 has been deprecated, so we can omit that one

[martin-strecker-sonarsource]

@cristian-ambrosini-sonarsource I think we looked at everything here and just forgot to close the issue, right?

[cristian-ambrosini-sonarsource]

Yes, we can close this issue.