What is the equivalent of [Serializable] in .NET Core ? (Conversion Projects)

Binary serialization has been removed from .Net Core due to the complexity and compatibility issues involved in serialization. Instead, it was decided that serialization should be protocol based instead. See: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/porting.md#binary-serialization

This really doesn't impact most use cases, as you can just use the XML Serializer or a third party package like json.net

To update the questions that are here.

Microsoft seemed to have ported SerializeAttribute to a seperate nuget package: System.Runtime.Serialization.Formatters

You can use this nuget package. Although i do not know why they added it later.

They removed it because they also removed binary serialization and it was mainly used for that. Maybe they still brought it back to create a basis for other type of serialization (like json, xml etc). because they still need the same bases (at least json): that you can't use interfaces or abstract properties, because de deserializer doesn't know which object to create for this property.

Maybe someone can shed some light on this situation, or i will when i know more.

What is SerializeableAttribute (origin)

The idea was you put this attribute on a class to tell it is serializeable that would mean:

• Object 'could not' have subclasses
• Properties on object mast be the concrete class (so no abstract class or interface)

Why?

because at deserialization the class and its properties are reflected and if reflection would find a interface as property it would have no idea which sub-class to create (the right dll might not even have been loaded, issues like this).

So in code:

public class NotSerializableObject {
    public IEnumerable<Test> property {get; set;}
}
public interface AlsoNotSerializableObject {
    List<Test> property {get; set;}
}
public class SerializableObject {
    public List<Test> property {get; set;}
}

Why was it 'deprecated'

There where many issues with this attribute and binary formatter itself (the only (de)serializer that actually checked for this attribute).

Problem with the Attribute: It could not be enforced during compile time so only at run time you will get errors, first: error you forgot the SerializableAttribute. and only later in runtime you get the error You cannot use IEnumerable since it is an interface. So it only create extra work instead of solving anything.

They didnt migrate this with the binary formatted because they saw it as depcreated or 'has to be redone' there where some major issues in it (something like this they said in one of their video talks/confs).

the only issue i found up to now in combination with IPC is that on DateTime object the Kind property was not (de)serialized.

But it is back in this nuget package: https://www.nuget.org/packages/BinaryFormatter/ .

And it seems like they even brought out a new version (2.1.0) which might indicate they want to prolong its livespan.

Why did they migrate it?

They are trying to move people onto there new 'Dotnet Core' (instead of full framework). And one of the strategies they use is by porting everything, even if they deem the code crappy as can be and should not be used by anyone/'better open source alternatives', so that it is easier for people to migrate their old code.

1 downside is that it is hard to find proper information on what nuget-packages/dll's should be considered 'crappy' and which nuget packages where totally redone from the ground up and are advised to be used again.

If you aren't serializing the type (that is, using BinaryFormatter), then you can remove [Serializable] and forget about it.

If you were using BinaryFormatter to serialize before, then you will need to come up with your own plan on how that will work (ie. via Json.net or XML).

If you are porting a library and asking on behalf of your consumers then the answer is the same: remove [Serializable] and leave serialization up to those who need it.