Remove BinaryFormatter usage from System.Resources.Extensions

[GrabYourPitchforks]

Ref:

runtime/src/libraries/System.Resources.Extensions/src/System/Resources/Extensions/DeserializingResourceReader.cs

Lines 37 to 48 in af828ae

	private object ReadBinaryFormattedObject()
	{
	if (_formatter == null)
	{
	_formatter = new BinaryFormatter()
	{
	Binder = new UndoTruncatedTypeNameSerializationBinder()
	};
	}
	return _formatter.Deserialize(_store.BaseStream);
	}

This issue tracks the removal and replacement of this code per the BinaryFormatter obsoletion plan.

Tagging subscribers to this area: @tarekgh, @buyaa-n, @krwq
Notify danmosemsft if you want to be subscribed.

[tarekgh]

CC @ericstj

[danmoseley]

Per the plan, this could maybe have the 6.0 milestone?

[ericstj]

Actually it's not clear to me from this doc why this code is removed or replaced. Why wouldn't we just let this be controlled by "disable BinaryFormatter" feature switch?

[GrabYourPitchforks]

BinaryFormatter is eventually going to be disabled by default across all project types, and for all new project types (wasm, etc.) it's permanently disabled with no way to re-enable it. Per the doc our eventual goal is that no aspect of the .NET runtime or first-party libraries should require developers to re-enable BinaryFormatter within their applications. Requiring users to re-enable it runs counter to our goal of improving the ecosystem. It's also going to be infeasible for certain code bases to re-enable support for BinaryFormatter since it will be perma-disabled for compliance reasons, regardless of project type.

[ericstj]

I see. The real work here would be to get @dotnet/dotnet-winforms and @dotnet/project-system to migrate off of using BinaryFormatter for types and move to one of the other supported formats (TypeConverter or Stream). We may also need to add some API (Stream ctors) or TypeConverters to support this scenario for types we own that don't currently work well in this scenario. We probably also need an migration tool that would convert binary-formatted payloads folks have checked into their source resx files and converts to a one of the new formats.

@GrabYourPitchforks maybe we should start by getting these teams to move to a new method and update the components which are producing BinaryFormatted payloads?

Here's a rough sketch of the order I'd see this happening:

1. Update ResXResourceWriter (and any other code in WinForms designer / project-system) to ensure that it gives precedence to safe formats, and fails rather than using BinaryFormatter.
2. Produce a migration tool that converts existing BinaryFormatted payloads -> safe formats, ideally just roundtripping through code updated in 1.
3. Introduce some type of warning/failure in MSBuild when it encounters these payloads and instructs folks to run tool from 2.
4. For any types which require work (TypeConverters or API) we add it based on feedback / discovery of errors after doing 3. We could probably proactively do some of this based on our existing data. Note that anything we do here wouldn't work on older frameworks if we just added the converters to the types. TypeConverters could be OOB-able if we register them on the consumption side (via TypeDesicriptor). We'd need to decide if it was important for this change to work on older frameworks, and if so we could do this registration in the DeserializingResourceReader.
5. Remove the use of BinaryFormatter in DeserializingResourceReader.

[merriemcgaw]

@dreddy-work . FYI. We need to start planning for this.

[ericstj]

cc @rainersigwald as well

[rainersigwald]

I believe there's also implication on the VS designers for .resx files.