В проекте какое-то время использовалась сериализация и было сохранено некоторое количество файлов с использованием BinaryFormatter. В какой-то момент сделали рефакторинг, перешли на другую систему версионности сборок, вынесли методы работы с файлами в отдельную сборку. Естественно десериализация данных вся посыпалась, файлы не читаются. Я наивный всегда предполагал, что в BinaryFormatter можно подставить свой биндер. Делаю биндер, а в биндер в BindToType() прилетают такие имена типов как System.RuntimeType или System.UnitySerializationHolder которые конечно же никуда не прибиндить. Ну и все не работает, данные не десериализуются. Есть ли какая-нибудь возможность в текущих версиях прочитать данные записанные в предыдущих версиях сборок?
Была проблема с бинарной (де)сериализацией -- требовала
определенную сборку, т.к. её метаданные куда-то там прописались.
Вроде победил тем,что подписывался на AppDomain.CurrentDomain.AssemblyResolve
и скармливал текущую сборку.
S>Была проблема с бинарной (де)сериализацией -- требовала S>определенную сборку, т.к. её метаданные куда-то там прописались. S>Вроде победил тем,что подписывался на AppDomain.CurrentDomain.AssemblyResolve S>и скармливал текущую сборку.
Нет, здесь сборка добавилась. Проблема прибиндить переименованные типы. Автоматом естественно оно не может, а свой биндер подключить невозможно, потому что a. BinaryFormatter использует привязку к типам internal в системных сборках, б. вообще теряется информация о типе, RuntimeType это потеря информации о типе.
И что мне теперь делать, бинарную сериализацию ф топку? Получается ее вообще лучше никогда не использовать? И вопрос более общий, поскольку вообще со всеми .NET сериалзациями вечные проблемы и костыли, нет ли какой-нибудь нормальной библиотеки на тему сериализации?
G>И что мне теперь делать, бинарную сериализацию ф топку? Получается ее вообще лучше никогда не использовать? И вопрос более общий, поскольку вообще со всеми .NET сериалзациями вечные проблемы и костыли, нет ли какой-нибудь нормальной библиотеки на тему сериализации?
Однозначно ф топку. Злейшее зло. Ссылку на protobuf уже дали.
Здравствуйте, QrystaL, Вы писали:
QL>Здравствуйте, grosborn, Вы писали: G>>нет ли какой-нибудь нормальной библиотеки на тему сериализации?
QL>http://code.google.com/p/protobuf-net/
Издеваетесь? Или у неё уже всё хорошо с Generic, списками, XmlDocument и наследованными классами ?
G>>>нет ли какой-нибудь нормальной библиотеки на тему сериализации?
QL>>http://code.google.com/p/protobuf-net/
N_P>Издеваетесь? Или у неё уже всё хорошо с Generic, списками, XmlDocument и наследованными классами ?
Я когда-то писал сериализацию даже на 1С и ничего в ней сложного нет. Почему же лучшие умы человечества неспособны решить эту задачу?
Здравствуйте, grosborn, Вы писали:
G>Я когда-то писал сериализацию даже на 1С и ничего в ней сложного нет.
И сколько человек в мире пользовались этой Вашей 1С-сериализацией ?
G>Почему же лучшие умы человечества неспособны решить эту задачу?
Потому что для общего случая эта задача нерешаема.
Сериализуемые объекты существуют не в вакууме. Они связаны с другими объектами, как входящими в сериализуемый граф, так и сторонними. Семантика этого связывания у каждой программы своя. Что и является первопричиной всех проблем.
D>Потому что для общего случая эта задача нерешаема.
А поясните, пожалуйста, почему? Вроде кол-во объектов конечно, все суть граф, и можно
пройтись по всем узлам и сериализовать, попутно отмечая уже сериализованные
объекты...
D>Сериализуемые объекты существуют не в вакууме. Они связаны с другими объектами, как входящими в сериализуемый граф, так и сторонними. Семантика этого связывания у каждой программы своя. Что и является первопричиной всех проблем.
Кстати занимаясь обменом между различными конфигурациями, можно свести все эти графы к обычным таблицам и некой простейшей иерархической Базе данных.
и солнце б утром не вставало, когда бы не было меня
G>>Я когда-то писал сериализацию даже на 1С и ничего в ней сложного нет.
D>И сколько человек в мире пользовались этой Вашей 1С-сериализацией ?
Много.
G>>Почему же лучшие умы человечества неспособны решить эту задачу?
D>Потому что для общего случая эта задача нерешаема.
Ухты, вот ведь как оно, Петрович.
D>Сериализуемые объекты существуют не в вакууме. Они связаны с другими объектами, как входящими в сериализуемый граф, так и сторонними. Семантика этого связывания у каждой программы своя. Что и является первопричиной всех проблем.
Первопричиной проблем конкретно в моем случае и поднятых в этой ветке криворукость микрософтовских программистов десериализующих объекты приватных классов. Если бы не баги кастомного биндинга все бы работало. Лучшие умы человечества просто не правят баги скорее всего известные с первых .нет версий.
Что за минус? Это слепая вера в безбажность дотнета или лоялизм? Если так несогласен, прочитай первое сообщение и попробуй предложить решение проблемы.
Здравствуйте, grosborn, Вы писали:
G>Что за минус? Это слепая вера в безбажность дотнета или лоялизм?
Это знание того, что никакой криворукости программистов МС тут нет, если неправильное использование BinaryFormatter
G> Если так несогласен, прочитай первое сообщение и попробуй предложить решение проблемы.
Его тут уже предложили.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
G>>Что за минус? Это слепая вера в безбажность дотнета или лоялизм?
AVK>Это знание того, что никакой криворукости программистов МС тут нет, если неправильное использование BinaryFormatter
Зачем врать-то? У него только один способ использования, его нельзя неправильно применить. И у биндера один способ применения, без вариантов, но он не работает. Или варианты озвученные ниже ты считаешь правильным использованием?
G>> Если так несогласен, прочитай первое сообщение и попробуй предложить решение проблемы.
AVK>Его тут уже предложили.
Зачем врать-то? Решения не было, даже мыслей как это можно решить не было озвучено. Есть файлы, есть переименованные типы в новой сборке. Ну я не знаю, патчить файл скажем, или лезть в исходники и цепляться рефлекшеном, или самое простое сделать фэйковые десериализуемые объекты с типами соответствующими старым сборкам, а потом из них данные копировать, варианты есть что лучше я не знаю. Предложение перейти на другой сериализатор это не решение, а скорее признание что прямого решения нет.
Здравствуйте, grosborn, Вы писали:
G>Зачем врать-то?
Слишком сильное утверждение в данной ситуации, не находишь?
G> У него только один способ использования, его нельзя неправильно применить.
Какой такой один способ?
G> И у биндера один способ применения, без вариантов, но он не работает.
У меня почему то работает.
G> Или варианты озвученные ниже ты считаешь правильным использованием?
Я считаю правильным использовать протокол с явным контрактом, например Protobuf. А BinaryFormatter предназначен прежде всего для ремоутинга (особенно в части кроссдоменного взаимодействия), где расползание сборок с контрактами недопустимо по куче других причин или просто невозможно, поэтому он может смело полагаться на внутренние детали реализации. Если же кто то решил использовать его вместо стандартизованных бинарных форматов или БД, то он ССЗБ, а не программисты в МС виноваты.
G>Решения не было, даже мыслей как это можно решить не было озвучено.
Было сказано неоднократно, что следует заменить BF на что то с управляемым и документированным форматом. Формат BF не документирован специально, чтобы на него ни в коем случае не закладывались.
G> Есть файлы, есть переименованные типы в новой сборке.
Простое переименование биндер отработает без проблем. А вот если данные по другому стали по классам раскладываться, тут уже все.
G>Предложение перейти на другой сериализатор это не решение, а скорее признание что прямого решения нет.
Это именно что правильное решение.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, grosborn, Вы писали:
G>елаю биндер, а в биндер в BindToType() прилетают такие имена типов как System.RuntimeType или System.UnitySerializationHolder которые конечно же никуда не прибиндить.
А зачем их биндить ручками, когда достаточно вернуть null:
// System.Runtime.Serialization.Formatters.Binary.ObjectReaderinternal Type Bind(string assemblyString, string typeString)
{
Type type = null;
if (this.m_binder != null) // m_binder - SerializationBinder
{
type = this.m_binder.BindToType(assemblyString, typeString); // Ваш код.
}
if (type == null)
{
type = this.FastBindToType(assemblyString, typeString); // Стандартная логика.
}
return type;
}
Ага, забавно, тебя плюсуют твои братья-лоялисты совершенно не читая что ты написал.
G>>Зачем врать-то?
AVK>Слишком сильное утверждение в данной ситуации, не находишь?
Так ведь бездумно защищаешь мс с помощью самопридуманных аргументов, заявлешь о каком-то знании которого на самом деле нет. Как это еще называется?
G>> У него только один способ использования, его нельзя неправильно применить.
AVK>Какой такой один способ?
Метод Serialize() он такой, опций практически нет. Для тебя это новость?
G>> И у биндера один способ применения, без вариантов, но он не работает.
AVK>У меня почему то работает.
Частный случай, мог бы и сам догадаться. Не используешь какие-то проблемные типы объектов. Истина где-то опять пролетает мимо тебя.
G>> Или варианты озвученные ниже ты считаешь правильным использованием?
AVK>Я считаю правильным использовать протокол с явным контрактом, например Protobuf. А BinaryFormatter предназначен прежде всего для ремоутинга (особенно в части кроссдоменного взаимодействия), где расползание сборок с контрактами недопустимо по куче других причин или просто невозможно, поэтому он может смело полагаться на внутренние детали реализации. Если же кто то решил использовать его вместо стандартизованных бинарных форматов или БД, то он ССЗБ, а не программисты в МС виноваты.
Видишь ли, сериализацию не в МС придумали и то что ты пишешь, ограничение на использование только в ремотинг, да еще и без расползание сборок, это ограничения кривой частной реализации в .НЕТ. В других реализациях, не в .нет таких ограничений нет и оно работает. И не требуется такого технического маразма как сохранение картинок в xml или в бд патамушта у нас бинарная сериализация как-то вот так работает. Хочешь знать как это должно быть сделано правильно?
BinaryFormatter это абстракция и, о новость для тебя, не должна зависеть от того, хочешь ли ты сериализант сохранить в файл или отправить его по сети и каким способом, и чем его хочешь прочитать. Функция привязки к версии и ключу сборки, которая сейчас прибита гвоздями к сериализации каждого объекта, эта функция должна быть внешней или опциональной, если она вообще нужна. Я всегда сериализовал без этих мудрствований и всегда все работало всего-лишь на идентификаторе формата пакета.
Так что все эти твои заявки верны с точностью до наоборот и просто смешны.
G>>Решения не было, даже мыслей как это можно решить не было озвучено.
AVK>Было сказано неоднократно, что следует заменить BF на что то с управляемым и документированным форматом. Формат BF не документирован специально, чтобы на него ни в коем случае не закладывались.
Следовало бы 1) допускать опционально привязку только по имени метаданных. Знаю что можно сделать через биндер, но это должно быть стандартной опцией. 2) исправить баги BinaryFormatter, что бы он не сериализовал объекты приватных классов. Откуда только он их берет, их нет в сериализуемых данных.
И, о чудо, работала бы и стандартная бинарная сериализация.
G>> Есть файлы, есть переименованные типы в новой сборке.
AVK>Простое переименование биндер отработает без проблем. А вот если данные по другому стали по классам раскладываться, тут уже все.
G>>Предложение перейти на другой сериализатор это не решение, а скорее признание что прямого решения нет.
AVK>Это именно что правильное решение.
Это следствие кривизны чьих-то рук, не будем показывать пальцем, хотя это конечно же МС.
G>>Делаю биндер, а в биндер в BindToType() прилетают такие имена типов как System.RuntimeType или System.UnitySerializationHolder которые конечно же никуда не прибиндить.
S>А зачем их биндить ручками, когда достаточно вернуть null:
Я всяко пробовал и null тоже. У нутрях у него неонка и никак не работает. Там принципиально не получается десериализовать, потому что видимо баг при сериализации, сериализуются объекты которые потом нельзя прибиндить биндером, а без биндера только фейковыми объектами, но их строить это лес и ломать текущую структуру классов потому что нельзя один класс отдельно заменить на фэйковый. В общем наверняка как-то это можно, но связано с дополнительными головняками и я пока забросил это дело.
Здравствуйте, grosborn, Вы писали:
AVK>>Слишком сильное утверждение в данной ситуации, не находишь? G>Так ведь бездумно защищаешь мс с помощью самопридуманных аргументов, заявлешь о каком-то знании которого на самом деле нет.
1) Бездумно — это твои личные заблуждения
2) Я не защищаю МС
3) О каком знании, как тебе показалось, я заявил?
G> Как это еще называется?
Ну уж никак не враньем.
G>>> У него только один способ использования, его нельзя неправильно применить. AVK>>Какой такой один способ? G>Метод Serialize() он такой, опций практически нет. Для тебя это новость?
Это не способ использования.
G>>> И у биндера один способ применения, без вариантов, но он не работает. AVK>>У меня почему то работает. G>Частный случай
Нет, просто я BF применяю правильно.
G>, мог бы и сам догадаться. Не используешь какие-то проблемные типы объектов. Истина где-то опять пролетает мимо тебя.
А может мимо тебя?
G>Видишь ли, сериализацию не в МС придумали
И что? В фреймворке много всяких сериализаций. И BinaryFormatter конкретно нельзя использовать в данных, которые мигрируют между разными версиями программы и фреймворков. Вот XmlSerializer или DataContractSerializer использовать можно, потому что формат сериализованных данных явным образом специфицируется. К сожалению, оба они текстовые, поэтому здесь и предложили использовать Protobuf-Net.
G>Так что все эти твои заявки верны с точностью до наоборот и просто смешны.
Какие именно?
G>исправить баги BinaryFormatter, что бы он не сериализовал объекты приватных классов.
Сериализация приватных данных это не бага, а фича. Без этого ремоутинг просто не будет работать. И биндер сделан вовсе не для того чтобы с версиями воевать, а для сериализации MBR объектов (через биндер Transparent Proxy зам еняется на ObjRef и обратно). То, что ты решил его использовать не по назначению — твоя личная проблема.
G> Откуда только он их берет, их нет в сериализуемых данных.
Есть. Точнее были.
AVK>>Это именно что правильное решение. G>Это следствие кривизны чьих-то рук
Конечно, того кто для долго живущих данных решил использовать BF.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK>3) О каком знании, как тебе показалось, я заявил?
Прочитай свои же посты и найдешь упоминанием о тайном знании.
G>> Как это еще называется?
AVK>Ну уж никак не враньем.
Вообще-то тут может быть три варианта, вранье, глупость и заблуждение. Выбирай.
G>>>> У него только один способ использования, его нельзя неправильно применить. AVK>>>Какой такой один способ? G>>Метод Serialize() он такой, опций практически нет. Для тебя это новость?
AVK>Это не способ использования.
О, это аргумент, да еще какой. Твой папа случайно не депутат, не?
AVK>Нет, просто я BF применяю правильно.
О да, метод один, опций нет, но ты его применяешь правильно, а другие нет. Дискуссия вышла на новый уровень.
G>>Видишь ли, сериализацию не в МС придумали
AVK>И что? В фреймворке много всяких сериализаций. И BinaryFormatter конкретно нельзя использовать в данных, которые мигрируют между разными версиями программы и фреймворков.
До тебя не доходит что это и есть кривизна. И то что для типовых задач применяется внешняя библиотека патамушта якобы внутренняя сильно правильная и ее использовать нельзя, тебя совсем не убеждает. И то что для сериализации нет разницы для чего ты ее используешь, ты конечно не знаешь.
G>>Так что все эти твои заявки верны с точностью до наоборот и просто смешны.
AVK>Какие именно?
Все.
G>>исправить баги BinaryFormatter, что бы он не сериализовал объекты приватных классов.
AVK>Сериализация приватных данных это не бага, а фича. Без этого ремоутинг просто не будет работать.
Опять бла-бла-бла, подтвердить свои слова ты не можешь.
AVK>И биндер сделан вовсе не для того чтобы с версиями воевать, а для сериализации MBR объектов (через биндер Transparent Proxy зам еняется на ObjRef и обратно). То, что ты решил его использовать не по назначению — твоя личная проблема.
Биндер якобы не для того что бы биндить. Ага-ага, мы верим, ага.
G>> Откуда только он их берет, их нет в сериализуемых данных.
AVK>Есть. Точнее были.
Не было там этих классов, там достаточно простая структура объектов и они там не нужны.
AVK>>>Это именно что правильное решение. G>>Это следствие кривизны чьих-то рук
AVK>Конечно, того кто для долго живущих данных решил использовать BF.
И это работает, но только в других языках и в других библиотеках. И только в .НЕТ с их прямыми руками это не работает. Ты случайно не в МС работаешь?
