Compat work for Serialization

[danmoseley]

Devise our plan for increasing compatibility with serialization, and break out the work.

[danmoseley]

Also see #17073

[stephentoub]

Remaining work:

• Port BinaryFormatter to corefx (Add BinaryFormatter to corefx corefx#10088)
• Disable custom serialization in coreclr until infrastructure available (Add #if FEATURE_SERIALIZATION around customized [Serializable]s coreclr#6263)
• Fix up serialization primitives in CoreCLR (Expose serialization primitives from System.Private.Corelib coreclr#6375, Add serialization primitives to mscorlib facade coreclr#6481, Add IObjectReference to model.xml coreclr#6485, Expose SerializationInfo.UpdateValue for corefx coreclr#6486, Add IObjectReference to mscorlib ref assembly coreclr#6488)
• Unify serialization primitive types with those in CoreCLR and move them to System.Runtime (Restore most serialization implementations in coreclr coreclr#6423) (Move serialization primitives to System.Runtime corefx#10667)
• Enable serialization on types in System.Private.CoreLib (Restore most serialization implementations in coreclr coreclr#6423)
• Expose serialization-related members from CoreCLR in CoreFx ref assemblies (Update System.Runtime ref assembly with coreclr serialization members corefx#11000, ...)
• Add tests for serializable types in System.Private.CoreLib (Add more serialization tests for core types corefx#10332)
• Port serialization implementations to types in CoreFx (in progress)
• Add tests for corefx serializable types
• Expose serialization-related members from CoreFx types in CoreFx ref assemblies
• Boost BinaryFormatter code coverage; currently at 80%, a few key code paths appear to be missing coverage
• Add core serialization types to corert

[AlexGhiondea]

@stephentoub do you know who is working on this?

[stephentoub]

@stephentoub do you know who is working on this?

At the moment, no one, at least not with a specific serialiation focus. In many places, it's happening organically as part of folks bringing up other components and adding back members, at which point they're adding back the relevant ones here.

At one point I'd written/run a little tool to mark the types that were in corefx that needed to be made serializable. This is out-of-date now, and some of this has already been done, but it'll help to highlight many of the places that need serialization work in corefx:
stephentoub/corefx@898da04

Please feel free to pick it up and run with it. I'd shelved this as the big blocker was that many of the involved projects hadn't yet been upgraded to netstandard1.7, which makes it a much bigger task. @ericstj was looking at making a pass through the repo to address that, at which point this should be easier.

[danmoseley]

Types missing ISerializable are tracked in https://github.com/dotnet/corefx/issues/12669

I'm wondering about [Serializable] attribute. That doesn't show up in the ref assys unfortunately.

[danmoseley]

[Serializable] tracked by https://github.com/dotnet/corefx/issues/12725
Missing members tracked by https://github.com/dotnet/corefx/issues/12254

I don't think we need issues for CoreRT work. 80% CodeCoverage seems pretty good compared to much of CoreFX so probably not worth tracking.

@stephentoub any missing tests you had in mind? If not let's close this issue now

[stephentoub]

[Serializable] tracked by dotnet/corefx#12725

Just note that for a type to be serializable, it must be [Serializable], but it may have additional serialization-related implementation, and some of that may not be visible by tracking missing members, e.g. there are [OnSerialized], [OnDeserialized], etc. attributes that can be used with [Serializable] and that wouldn't show up in a missing-member scan. We can still track the missing serialization work via [Serializable], but whoever does that work just needs to be aware that there may be things elsewhere in the class being attributed that needs to be fixed, too.

I don't think we need issues for CoreRT work.

Ok

any missing tests you had in mind?

There are two categories:

1. Tests for BinaryFormatter
2. Tests for specific [Serializable] implementations

I'm ok closing this for the first one, as I don't have any specific cases in mind, just that we're not hitting 20% of BinaryFormatter's implementation, which is much more than I'd like. For the second, I'm also ok not tracking it here, as long as whoever adds each [Serializable] implementation adds appropriate tests with it.