Прочитал что есть 3 вида сериализации. Какой из 3х подойдет в моем случае:
Есть tabPage контрола tabControl, на tabPage хранятся некие настройки которые использует программа. tabPage содержит ListCheckBox, textBox, dateTimePicker и кнопки. Мне необходимо организовать сохранение настроек (состояния объекта).
Хотелось бы услышать правильно ли использовать сериализацию в данном случае, если да то какой из 3х видов больше подойдет?

Оказывается сериализация контролов дело не благодарное и не правильно. 

Вместо сериализации контролов нужно сохранять значения их свойств. Если речь идёт о настойках самой программы - надо использовать Application Settings. Создавать нужные свойства для хранения можно либо в свойствах проекта(вкладка сеттингс), либо прямо в дизайнере формы при активации контрола в его свойствах надо найти Application Settings и связать интересующие свойства с сеттингами(либо созданными ранее, либо можно там же их и создать)

Да, но как же поступать с запоминанием настроек CheckListBox, в Application Settings я не нашел настройку для сохранения галочек Items'ов?

Запоминаются не все настройки оптом, а только нужные свойства. В данном случае надо создать булево свойство в сеттингах, и сохранять в него состояние чекбокса. Всякий раз, когда нужно сохранить галочку - на самом деле эта галочка что-то значит. Сохранять надо то, что она значит. В случае с чекдлистбоксом  речь, видимо, идёт о сериализации не самого листбокса, а его свойства Items, только к сериализации контролов это отношения не имеет. Надо обойти коллекцию и сохранить свойства объектов, в ней содержащихся. Возможность сериализовать сами объекты, используя стандартные механизмы сериализации зависит от типа объектов(нужно проверить у них наличие соответствующих атрибутов - Serializable и т. д.). Но в общем случае ничто не мешает проверить у объектов интересующие свойства, вставить их в како-нибудь документ(простой XML формат например) и сохранть его в тех же сеттингах.
А из дизайнера можно сохранять только свойства самих компонентов. Так что если интересует такой способ, то вместо чекдлистбокса можно простые чекбоксы исползовать, но это только для тех случаев когда сам список не меняется.

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

А если в следующей версии программы ты захочешь добавить несколько настроек? Класс прийдётся дописать. Процедуру извлечения данных из формы переписать. Процедуру вставки данных в форму...
А оно тебе надо? К тому же переписать код, написанный недавно - нетрудно, а по прошествии времени прийдётся во всё заново вникать. Конечно способ сохранения настроек надо выбирать в зависимости от задач(которых я не знаю), но всякий раз, когда ты отходишь от стандартных процедур, оказывается, что надо учитывать ещё массу вопросов. По-моему ничего лучшего, чем связываение с сохраняемыми свойствами ещё не придумали. Так что для выбора другой техники нужны серьёзные основания, в ином случае лучше ограничиться стандартными инструментами, благо их довольно много.

Например.

Ну, для сохранения настроек лучше связывания сохраняемых свойств с сетингами ничего порекомендовать не могу. Если речь идёт о каком то свойстве, котрое не получается сохранить так - его можно сохранить отдельно, но для остальных свойств ничего не стоит изобретать. Чем сложнее механизм - тем труднее его изменить при необходимости.
В частности чекдлистбокс может содержать список простых текстовых значений и чекбоксы. Если в твоём случае это так, то для его содержимого, можно в сеттингах создать простое текстовое поле и хранить к примеру в таком формате. Например такое содержимое

можно представить текстом

для сохранения обойти все элементы и сформировать такую строку, а для загрузки просто разбить её при помощи String.Split на отдельные строки и там уже выпарсить значения не проблема. 
Ну это только вариант, можно, конечно и класс специальный создать, но уж чего точно не стоит делать, так это все настройки в него пихать. Мало ли вдруг переделывать что-то прийдётся.

Если ты уверен,что твоя программа будет использована на платформе МС(Виндоуз),то смело используй BinaryFormatter,но если есть шанс пользования скажем в Linux,то желательно,а точнее обязательно исвользование XmlFormatter'а.
Как ты наверно заметил последний вариант стал достаточно популярным в последнее время(МС сохраняет доковские файлы в openXML,другие пакеты,например маткад тоже сохраняет в этом формате)
Плюс нужно исходить из того,что тебе нужно сериализовать:в твоем случае-это конфиг файл с настройками,поэтому  я бы использовал XMLFormatter

Dictionary<string, Dictionary<string,object>> ?
структура вида: Namespace -> ConfigName -> object

потом к ней класс два класса (один представляет "мешок свойств", второй "свойство, имеющее имя") и пожалуйста, извлекайте из него что вам надо, по имени свойства. А сам класс сериализуйте.... впрочем, так поступает ConfigManager

Вариант хороший. 
Поскольку у меня список в ЧекЛистБоксе статический, я откажусь от использования чеклистбокса и начну использовать просто checkbox'ы там и ApplicationSettings можно хранить для свойства Checked. 

diadiavova, создать простое текстовое поле я так и не понял где, список ApplicationSettings строго зашит, насколько я понимаю, и привязан к каждому конкретному полю класса CheckedListBox.

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

В меню Project открой свойства проекта, там есть вкладка (по-моему она так и называется Settings), на ней ты найдёшь все сетинги созданные в различных дизайнерах, кроме того, легко можешь создавать свои собственные. При этом любой сетинг в последствии можно привязать к свойству компонента на в любом дизайнере. Тебе даже код, читающий эти свойства писать не прийдётся. Просто привяжешь интересующее тебя свойство к нужному сетингу и они будут связаны, то есть изменение одного приведёт к изменению другого. 
Кстати, типов свойств, которые можно в сетингах создавать тоже довольно много. Это не только примитивы и строки. И если ты используешь эти типы, то сериализация будет выполняться автоматом, при присвоении этим свойствам значения. А сделать это можно будет как при помощи связанных свойств, так и напрямую из кода. Все сетинги доступны из любой точки приложения.
Поэтому я и написал, что если список в чекдлистбоксе статический, то лучше использовать чекбоксы, и для каждого свой сетинг создать. Главное преимущество, которое ты получишь от этого в том, что вместо написания собственного кода можно использовать встроенные механизмы, и делать всё в дизайнере. Во первых это легче, а во-вторых в собственном коде вероятность ошибки выше, чем при использовании стандартных инструментов.
Что до сериализации, ИМХО, её как раз для сохранения настроек следует использовать только в одном случае - если очень сильно хочется. А так это просто ни к чему.

Это сообщение отредактировал(а) diadiavova - 21.10.2008, 10:10

ХЕХ...

давайте разеремся.

есть внутрение сеттинги и внешние.
внутрение -- в свойствах проекта, переходят в константы в сборке.
для внешних есть app.config. Для доступа к ним используется System.Configuration.ConfigurationManager
внешние подразделяются на два "уровня": Application и User.
Первые служат для настройки всего приложения (например - общая строка (без пароля и логина)) соединения с БД. Размещаются рядом с приложение file.exe.config
Вторые для кастомизации под конкретного пользователя. Размещаются в %USER_HOME%\Local Settings\ApplicationData\NameOfYourApp\version\user.config. Файл создасться автоматом при изменении юзерных настроек. Все что вы зададите при создании приложения уровня User будет прописано в сборку как константы, и будет использовано как значения по умолчанию. Изменяется используя Properties.Settings.Default.YourProperty = value; сохраняется после Properties.Settings.Default.Save()

Если много сборок - конфиг будет один, тока хитрой структуры.. но это уже другая песня...

Вот это

всего-навсего о твет на это

А вот этим

Пожалуй воспользуюсь.