Что эквивалентно [Serializable] в .NET Core? (Проекты конверсии)

Во многих случаях, когда я хочу преобразовать текущие проекты .NET Framework в эквивалент .NET Core, некоторые классы имеют атрибут Serializable.

Что делать для преобразования их в .NET Core? (В это время я удаляю их!!!)

ИЗМЕНИТЬ

Рассмотрим этот код:

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)
        {
        }
    }
}

выше код без [Serializable] работает в .NET Core без проблемы синтаксиса.

Но я хочу знать, когда я удаляю [Serializable]

Что такое побочные эффекты?

Какие места следует изменить?

Когда следует использовать JSON.NET(или...) вместо [Serializable]?

Ответ 1

Если вы не сериализуете тип (то есть, используя BinaryFormatter), вы можете удалить [Serializable] и забыть об этом.

Если вы раньше использовали BinaryFormatter для сериализации, тогда вам нужно будет придумать собственный план того, как это будет работать (например, через Json.net или XML).

Если вы портируете библиотеку и спрашиваете от имени своих клиентов, тогда ответ будет таким же: удалите [Serializable] и оставьте сериализацию до тех, кто в ней нуждается.

Ответ 2

Чтобы обновить вопросы, которые находятся здесь.

Microsoft, похоже, портировала SerializeAttribute в отдельный пакет nuget: System.Runtime.Serialization.Formatters

Вы можете использовать этот пакет nuget. Хотя я не знаю, почему они добавили его позже.

Они удалили его, потому что они также удалили двоичную сериализацию, и в основном это использовалось для этого. Возможно, они все еще вернули его, чтобы создать основу для другого типа сериализации (например, json, xml и т.д.). потому что им по-прежнему нужны одни и те же базы (по крайней мере, json): вы не можете использовать интерфейсы или абстрактные свойства, потому что десериализатор не знает, какой объект создать для этого свойства.

Возможно, кто-то может пролить свет на эту ситуацию, или я буду, когда узнаю больше.

Что такое SerializeableAttribute (origin)

Идея заключалась в том, что вы поместили этот атрибут в класс, чтобы сказать, что он сериализуем, что означало бы:

Объект "не может" иметь подклассы
Свойства на мачте объекта будут конкретным классом (поэтому нет абстрактного класса или интерфейса)

Почему?

потому что при десериализации класс и его свойства отражаются, и если отражение найдет интерфейс как свойство, он не имел бы представления о том, какой подкласс должен создать (правильная dll, возможно, даже не была загружена, такие проблемы).

Итак, в коде:

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;}
}

Почему он "устарел"

Там, где много проблем с этим атрибутом и самим бинарным форматированием (единственный (де) сериализатор, который фактически проверял этот атрибут).

Проблема с атрибутом: она не может быть применена во время компиляции, поэтому только во время выполнения вы получите ошибки, во-первых: ошибка, которую вы забыли, SerializableAttribute. и только позже во время выполнения вы получите ошибку. Вы не можете использовать IEnumerable, так как это интерфейс. Таким образом, он создает дополнительную работу вместо того, чтобы что-либо решать.

Они не перенесли это с двоичным отформатированным, потому что видели, что он был скомпонован или "должен быть переделан" там, где некоторые важные проблемы в нем (что-то вроде этого они сказали в одном из своих видео-переговоров/confs).

Единственная проблема, которую я обнаружил до сих пор в сочетании с IPC, заключается в том, что на объекте DateTime свойство Kind не было (де) сериализовано.

Но он вернулся в этот пакет nuget: https://www.nuget.org/packages/BinaryFormatter/.

И похоже, что они даже выпустили новую версию (2.1.0), которая может указывать на то, что они хотят продлить срок ее службы.

Почему они перенесли его?

Они пытаются переместить людей на новое "Dotnet Core" (вместо полной рамки). И одна из стратегий, которые они используют, - это все портировать, даже если они считают, что код дерьмовый, какой может быть и не должен использоваться кем-либо/лучше альтернативы с открытым исходным кодом, так что людям легче переносить старый код.

Недостатком

1 является то, что трудно найти правильную информацию о том, что nuget-packages/dll следует считать "crappy" и какие пакеты nuget полностью переделаны с нуля и рекомендуется использовать снова.

Ответ 3

Двоичная сериализация была удалена из .Net Core из-за сложности и проблем совместимости, связанных с сериализацией. Вместо этого было решено, что сериализация должна основываться на протоколе. См.: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/porting.md#binary-serialization

Это действительно не влияет на большинство случаев использования, так как вы можете просто использовать XML-сериализатор или сторонний пакет, например json.net

Ответ 4

Обновить до данного ответа:

.Net Core 2.0 теперь поддерживает двоичную сериализацию для подмножества типов, вы можете увидеть полный список здесь