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

класс, экземпляр которого я сериализую
namespace PDU
{
[Serializable]
public class PDUFlashSlot : Library.UserSerialize.UserSerialize, ISerializable
{
...................
}
}
Сериализация
PDUFlashSlot data;
............
BinaryFormatter ser = new BinaryFormatter();
ser.Serialize(file , data);

десериализация
BinaryFormatter ser = new BinaryFormatter();
PDUFlashSlot data= (PDUFlashSlot)ser.Deserialize(file);
Программа получила развитие, соотвественно проект разросся, я решил навести порядок в проекте (конечно лучше бы всем этим начал заниматься с самого начала )
Вобщем начал распихивать классы реализованные ранее по разным namespace.

перенес описание класса PDUFlashSlot в
namespace Library
{
[Serializable]
public class PDUFlashSlot : Library.UserSerialize.UserSerialize, ISerializable
{
...................
}
}

В итоге получил проблемы с десериализацией объектов, которые были сериализованны ранее, когда описание класса находилось в namespace PDU.
Возможно кто то сталкивался с такой проблемой, подскажите пожалуйста как ее можно решить?

Здравствуйте, BUTEK, Вы писали:

BUT>В итоге получил проблемы с десериализацией объектов, которые были сериализованны ранее, когда описание класса находилось в namespace PDU.
BUT>Возможно кто то сталкивался с такой проблемой, подскажите пожалуйста как ее можно решить?

Плавали, знаем Для решения проблемы нужно сделать свою реализацию класса SerializationBinder и подсунуть её форматтеру с помощью свойства Binder. Вообще из-за этого гемора я недолюбливаю бинарную сериализацию...

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, BUTEK, Вы писали:

BUT>>В итоге получил проблемы с десериализацией объектов, которые были сериализованны ранее, когда описание класса находилось в namespace PDU.
BUT>>Возможно кто то сталкивался с такой проблемой, подскажите пожалуйста как ее можно решить?

K>Плавали, знаем Для решения проблемы нужно сделать свою реализацию класса SerializationBinder и подсунуть её форматтеру с помощью свойства Binder. Вообще из-за этого гемора я недолюбливаю бинарную сериализацию...

а чем порекомендуете пользоваться для хранения даных?

Здравствуйте, <Аноним>, Вы писали:

А>а чем порекомендуете пользоваться для хранения даных?

Включить моск и качественно проработать формат хранения данных, коль скоро совместимость оказалась критична. Форматы обычно живут много дольше конкретной версии конкретного приложения.

Здравствуйте, AndrewVK, Вы писали:

AVK>Включить моск и качественно проработать формат хранения данных, коль скоро совместимость оказалась критична. Форматы обычно живут много дольше конкретной версии конкретного приложения.

Со своей стороны посоветую в этом формате хранить версию формата (пока что 1.0) и предусмотреть, насколько это позволяет фантазия, возможность расширения формата, так, чтобы будущие изменения не нарушили его стройность и логичность.

Здравствуйте, AndrewVK, Вы писали:

AVK>Включить моск и качественно проработать формат хранения данных, коль скоро совместимость оказалась критична. Форматы обычно живут много дольше конкретной версии конкретного приложения.

+1. Бинарная сериализация — худший из возможных вариантов, ибо данные в этом формате почти не поддаются обработке. Даже XML-сериализация куда лучше, т.к. в крайнем случае при изменении схемы на данные можно накатить XSLT и привести их формат к пригодному для загрузки. Ну и, как тут справедливо заметили, обязательно нужно предусмотреть наличие неизменяемого заголовка с версией формата — по ней можно будет определить, какой парсер использовать.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, AndrewVK, Вы писали:

AVK>>Включить моск и качественно проработать формат хранения данных, коль скоро совместимость оказалась критична. Форматы обычно живут много дольше конкретной версии конкретного приложения.

PD>Со своей стороны посоветую в этом формате хранить версию формата (пока что 1.0) и предусмотреть, насколько это позволяет фантазия, возможность расширения формата, так, чтобы будущие изменения не нарушили его стройность и логичность.

Версия у меня как раз есть, и формат с помощью пользовательской сериализации я без проблем менял уже несколько раз.
Структуру данных продумать за ранее не могу, потомучто струткура сильно зависит от устройтсва с которого я читаю данные, разговоры на тему давайте жить дружно и совместными усилиями проработаем структуру хранения, обычно заканчиваются :"Ну ты понимаешь у нас железка ресурс ограниченый, а у тебя PC. Да и мы не виноваты, сейчас сказали сделать так, завтра по другому...."

Вопрос был не в этом, а в том что я перенес описание класса из одного namespace в другой

Здравствуйте, Аноним, Вы писали:


А>Вопрос был не в этом, а в том что я перенес описание класса из одного namespace в другой

На этот вопрос тебе вроде как ответили, ну а мой комментарий был к замечанию Андрея.

Здравствуйте, koandrew, Вы писали:

AVK>>Включить моск и качественно проработать формат хранения данных, коль скоро совместимость оказалась критична. Форматы обычно живут много дольше конкретной версии конкретного приложения.

K>+1. Бинарная сериализация — худший из возможных вариантов, ибо данные в этом формате почти не поддаются обработке.

Странная причина. У бинарного формата есть, во-первых, свои преимущества: а во-вторых, …

K>Даже XML-сериализация куда лучше, т.к. в крайнем случае при изменении схемы на данные можно накатить XSLT и привести их формат к пригодному для загрузки. Ну и, как тут справедливо заметили, обязательно нужно предусмотреть наличие неизменяемого заголовка с версией формата — по ней можно будет определить, какой парсер использовать.

…при наличии "неизменяемого заголовка" — выбор формата на самом деле дело уже двадцать пятое. В случае xml точно такой же заголовок с версией потребуется, что бы узнать каким образом что трансформировать. Xml конечно удобно, но двоичный формат компактен — в каждом случае можно выбрать что либо самое подходящее, а вот система: некий заголовок с версией и, возможно, какой-то дополнительной метаинформацией, — штука полезная при любом формате.

Здравствуйте, _FRED_, Вы писали:

K>>+1. Бинарная сериализация — худший из возможных вариантов, ибо данные в этом формате почти не поддаются обработке.

_FR>Странная причина. У бинарного формата есть

Ты вообще внимательно сообщение прочел?

Здравствуйте, AndrewVK, Вы писали:

K>>>+1. Бинарная сериализация — худший из возможных вариантов, ибо данные в этом формате почти не поддаются обработке.
_FR>>Странная причина. У бинарного формата есть
AVK>Ты вообще внимательно сообщение прочел?

Я как-то и представить не мог, что загвоздка не в слове "бинарная", а в термине предлагаемой фреймворком технологии — ты же это имеешь в виду?

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

Здравствуйте, _FRED_, Вы писали:

FR>Я как-то и представить не мог, что загвоздка не в слове "бинарная", а в термине предлагаемой фреймворком технологии — ты же это имеешь в виду?

И не только я.

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

Точно топик не читал.

BinaryFormatter ser = new BinaryFormatter();
ser.Serialize(file , data);

Речь, как видишь, не о бинарном формате вообще, а о вполне конкетном BinaryFormatter

Здравствуйте, AndrewVK, Вы писали:

_FR>>И бинарную сериализацию можно "готовить" правильно, достаточно (хотя вариантов много) сериализуемые данные хранить в контейнере с версией и метаданными.
AVK>Точно топик не читал.

Читал. Если бы потрудился более конкретно указать на то, что имеешь в виду, возможно я скорее бы тебя понял.

AVK>

AVK>BinaryFormatter ser = new BinaryFormatter();
AVK>ser.Serialize(file , data);
AVK>

AVK>Речь, как видишь, не о бинарном формате вообще, а о вполне конкетном BinaryFormatter

Речь в стартовом сообщении идёт о том, как десериализовать "старые данные". Я же отвечал на то, что "Бинарная сериализация — худший из возможных вариантов". Мой ответ к теме топика имеет тоже отношение, что и советы о том, как надо было правильно сериализовать — топикстартеру-то всё одно это не поможет

А вот в тему "чем порекомендуете пользоваться для хранения даных" мой ответ к месту — бинарная сериализация вполне нормальный инструмент, если им правильно пользоваться, так что смысл твоих возражений мне попросту не понятем. Не можешь всё-таки разъяснить их без недомолвок и намёков напрямую?

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, BUTEK, Вы писали:

BUT>>В итоге получил проблемы с десериализацией объектов, которые были сериализованны ранее, когда описание класса находилось в namespace PDU.
BUT>>Возможно кто то сталкивался с такой проблемой, подскажите пожалуйста как ее можно решить?

K>Плавали, знаем Для решения проблемы нужно сделать свою реализацию класса SerializationBinder и подсунуть её форматтеру с помощью свойства Binder. Вообще из-за этого гемора я недолюбливаю бинарную сериализацию...

Спасибо, заработало) здорово

Потому всегда клепал свою собственную сериализацию/десериализацию, что и вам всем советую.

Здравствуйте, _FRED_, Вы писали:

_FR>… Xml конечно удобно, но двоичный формат компактен — в каждом случае можно выбрать что либо самое подходящее, а вот система: некий заголовок с версией и, возможно, какой-то дополнительной метаинформацией, — штука полезная при любом формате.

Xml можно заархивировать