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

Question

In many cases, when I want to convert current .NET Framework projects to .NET Core equivalent, some classes have Serializable attribute.

What should I do for convert them in .NET Core ? (In this time I delete them !!!)

EDIT

Consider this code :

using System;  namespace DotLiquid.Exceptions {     [Serializable] // I delete it now !!!!!!!     public class FilterNotFoundException : Exception     {         public FilterNotFoundException(string message, FilterNotFoundException innerException)             : base(message, innerException)         {         }          public FilterNotFoundException(string message, params string[] args)             : base(string.Format(message, args))         {         }          public FilterNotFoundException(string message)             : base(message)         {         }     } } 

above code without [Serializable] works in .NET Core without syntax problem.

But I want to know when I delete [Serializable]

What is side effects ?

What places should be changed?

When should I use JSON.NET (or ...) instead of [Serializable] ?

Answer 1

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.