«Exception.Exception(SerializationInfo, StreamingContext)» устарело» – лучшая практика реализации исключений?
Я написал подкласс Exception в своем проекте C#, ориентированном на .NET 8.0, и шаблон в IDE автоматически заполнил знакомый конструктор сериализации (тот, который принимает SerializationInfo и StreamingContext), и теперь сборка предупреждает меня:
warning SYSLIB0051: 'Exception.Exception(SerializationInfo, StreamingContext)' is obsolete:
'This API supports obsolete formatter-based serialization. It should not be called or
extended by application code.' (https://aka.ms/dotnet-warnings/SYSLIB0051)
Какова здесь лучшая практика? Проблематично ли включить этот конструктор? Нет ли в .NET 8.0 обстоятельств, при которых его можно было бы вызвать? Его пропуск технически означает нарушение контракта, не так ли?
Означает ли это, что вся сериализация на основе форматтера теперь считается устаревшей? Или сериализация объектов Exception на основе форматтера считается устаревшей? Это потому, что сериализация на основе форматера для объектов Exception исторически использовалась в основном для удаленного взаимодействия .NET, а удаленное взаимодействие .NET не было перенесено в .NET Core или более поздние версии .NET Framework, и поэтому ожидается, что никто не будет когда-нибудь снова использовать сериализацию на основе форматера??
Итог: неужели мы просто больше не будем делать этот конструктор? На данный момент считается приемлемым писать Exception классы, которые не проходят сериализацию на основе форматера?
«Означает ли это, что вся сериализация на основе форматеров теперь считается устаревшей?» - существует уже довольно продолжительное время. У меня нет ссылки, но я вполне уверен, что вижу эти предупреждения уже… не знаю месяцев, если не лет.
Если вы перейдете по ссылке... «Начиная с .NET 8 Preview 4 [...] весь тип BinaryFormatter теперь устарел из-за ошибки». - что довольно однозначно: они не хотят, чтобы вы использовали или поддерживали что-либо из этого. И далее говорится: «Код, который ссылается на эти типы, даже если он не вызывает методы Serialize или Deserialize, будет наблюдать сбои компиляции в .NET 8». ... вот и все.
Ответы 1
Да, BinaryFormatter и все его зависимые типы устарели в .NET 8.0 и выдадут ошибку (как вы также можете видеть по ссылке , указанной в сообщении об ошибке). Вы по-прежнему сможете отключить эту ошибку, но в .NET 9.0 эта функция будет окончательно удалена из среды выполнения.
Поскольку конструктор Exception.Exception(SerializationInfo, StreamingContext) используется (только) для десериализации с использованием BinaryFormatter, он также устарел, включая все производные конструкторы. Это, кстати, относится и к методу GetObjectData(SerializationInfo, StreamingContext).
Итак, ваше предположение верно: вы можете (и должны) просто удалить этот конструктор вместе с методом GetObjectData из любого имеющегося у вас пользовательского типа исключения при обновлении до .NET 8.0. Если вы не используете BinaryFormatter (чего вам больше не следует делать), они никогда не будут вызываться и, следовательно, могут быть безопасно удалены. Если вы пишете собственную инфраструктуру сериализации, вам необходимо сериализовать/десериализовать исключения другим способом.
Помню, было даже предупреждение, когда конструктор десериализации отсутствовал в более ранних версиях .NET, но и этого, конечно, тоже нет.
[Справочная информация: Да, двоичное форматирование использовалось как часть удаленного взаимодействия, но не отдельно. Люди также использовали его для сериализации объектов на диск или других интересных вещей, поскольку он был очень удобен и прост в использовании. Причина, по которой делается этот давно подготовленный шаг, заключается в безопасности: двоичный (де)сериализатор не был разработан с учетом безопасности и не может быть исправлен, поскольку он по сути копирует весь объект в необработанном виде в память, что делает его уязвимым. для атак на переполнение буфера и других неприятных вещей]
Джонатан: для получения дополнительной информации используйте свою любимую поисковую систему с надписью «BinaryFormatter сломан и не может быть исправлен».
«Проблематично ли включить этот конструктор?» - Предупреждение пытается вас убедить именно в этом. Это означает, что, возможно, уже при следующем обновлении dotnet (ну, возможно, не «следующем», но скоро), это может стать критическим изменением, и вам придется удалить этот код.