Use preserialized resources to target Core 3

[rainersigwald]

Opts into the new System.Resources.Extensions approach to resource
serialization when targeting .NET Core 3.0+/.NET Standard 2.1+.

Respects project setting if the project explicitly sets the property, to
allow opting .NET Framework-targeting applications to opt in.

This is my stake-in-the ground proposal: light this up automatically for the folks who definitely need it. Happy to have discussion about other times when we should set this.

Important factors include:

• TF of the project, including whether that TF has S.R.Extensions guaranteed
• runtime of the building MSBuild (Core MSBuild can't support the legacy approach needed for targeting full without adding the S.R.Extensions reference to the project)

@nguerrera @livarcocc @ericstj @merriemcgaw @dreddy-work

(this property does nothing but is harmless until it runs in conjunction with dotnet/msbuild#4420; posting this now to review in parallel)

[ericstj]

System.Resources.Extensions is not part of .NETStandard2.1 and the package itself works on .NETStandard2.0. What's the reasoning for tying this to 2.1? Will it still check for the presence of S.R.E in references?

[rainersigwald]

Misunderstanding: I thought it was part of standard2.1. Restricting to the known-good .NET Core 3.0+ case.

[ericstj]

So if I want to enable this on another framework I need to reference the System.Resources.Extensions package and set GenerateResourceUsePreserializedResources=true?

[rainersigwald]

That's the current state. Do we have a better idea of what's "right"?

[ericstj]

I think that's fine, just wanted to clarify.

I agree that we need more than just the reference, because the package might be a transitive dependency. So I am fine with both the flag and the reference, so long as we check that the reference is present when the flag is set, so that we don't get unexpected run-time issues.