Remove support for serialization?

[stakx]

This is a continuarion of #501. We ended up questioning whether or not DynamicProxy should retain special support for serialization (this actually encompasses a few different aspects). I think this question deserves a dedicated issue.

[stakx]

My personal opinion on the matter: DynamicProxy focuses mostly on binary serialization (with a wee bit of XML serialization thrown in), and that is mostly obsolete in all recent .NET versions. We should probably cut off that historical baggage at some point. This can only happen in a major release (e.g. now, for v5).

Removing binary serialization will not affect saving generated assemblies to disk (which is important for us to run tests); but one would no longer be able to load them back into a proxy generator's type cache. That latter public API would have to go, too.

That being said, I don't have strong feelings on this. If we can't agree to remove it for v5, I'll go along with retaining binary serialization support for now.

These days, we should probably focus much more on JSON and XML serialization. Support for that can be added in any minor release.

[csharper2010]

Hi,

just saw this...

We use the serialization and deserialization of Castle.Core to save and restore proxy assemblies for performance reasons in a large app. We still use .NET Framework 4.8 for several reasons.

Knowing that the System.RuntimeType is not serializable in .net 5 this saving and loading would anyway not work, I still wonder if there could be a solution directly baked into Castle.Core. Advantage of built-in support would be to always have consistent cache mappings directly inside the generated assembly. Home brewing something to somehow save and restore the mappings would need a separate place to store the mapping and could lead to inconsistent information in assembly and mapping.

Some projects build serialization surrogates for their classes containing System.Type properties or just save the type's full name. I don't have any experience yet how reliable such a solution would be in .net 5 but do you see realistic chances for that?

Would be kind giving us some hints.

[stakx]

@csharper2010, the biggest issue is that .NET Core and .NET ≥ 5 don't currently offer any means of saving a dynamic assembly to disk. Without that essential capability, we don't even need to think about how we would serialize problematic types such as System.[Runtime]Type, because proxy serialization as a whole becomes pointless.

If you rely on proxy serialization, and you want to keep using DynamicProxy, your only real option for now is to remain on the .NET Framework 4, and to keep using a version of DynamicProxy that still supports binary serialization (in case that we're going to remove that capability at some point).

I'll mention something else since performance seems to be an important consideration in your case: The recent introduction of Roslyn source generators has brought us a few new libraries that generate their proxy types at compile-time; see e.g. Avatar or (to a lesser degree) SourceMock. By doing so, there's no more need to save and load proxy type assemblies, or to maintain a proxy type cache. I cannot say how well those libraries would work with a serialization method of your choice, but such compile-time proxies aren't fundamentally different from any other objects.