То, чего я хочу достичь, очень просто: у меня есть приложение Windows Forms (.NET 3.5), которое использует путь для чтения информации. Этот путь может быть изменен пользователем с помощью формы параметров, которую я предоставляю.
Теперь я хочу сохранить значение пути в файл для дальнейшего использования. Это будет одна из многих настроек, сохраненных в этом файле. Этот файл будет находиться прямо в папке приложения.
Я понимаю, что доступны три варианта:
- Файл настроек конфигурации (appname.exe.config)
- реестр
- Пользовательский файл XML
Я прочитал, что файл конфигурации .NET не предназначен для сохранения значений обратно в него. Что касается реестра, я хотел бы получить как можно дальше от него.
Означает ли это, что я должен использовать пользовательский файл XML для сохранения настроек конфигурации?
Если это так, я хотел бы увидеть пример кода (C #).
Я видел другие дискуссии на эту тему, но мне все еще не ясно.
Ответы:
Если вы работаете с Visual Studio, то получить постоянные настройки довольно просто. Щелкните правой кнопкой мыши проект в обозревателе решений и выберите «Свойства». Выберите вкладку «Настройки» и нажмите на гиперссылку, если настройки не существуют.
Используйте вкладку «Настройки» для создания настроек приложения. Visual Studio создает файлы
Settings.settings
иSettings.Designer.settings
которые содержат класс одноплодной ,Settings
унаследованный от ApplicationSettingsBase . Вы можете получить доступ к этому классу из своего кода для чтения / записи настроек приложения:Этот метод применим как для консоли, Windows Forms, так и для других типов проектов.
Обратите внимание, что вам нужно установить область свойство ваших настроек. Если вы выберите Область приложения, тогда Settings.Default. <Ваше свойство> будет доступно только для чтения.
Ссылка: Как: записать пользовательские настройки во время выполнения с C # - Microsoft Docs
источник
Settings.Default.SomeProperty = 'value'; Settings.Default.Save();
работает как шарм. Или это потому, что у меня есть пользовательские настройки?Settings.Default.Save()
ничего не делает, неверно. Как пишет @aku в ответе, настройки области приложения доступны только для чтения: сохранение для них неэффективно. Используйте этот пользовательский PortableSettingsProvider для сохранения настроек области пользователя в файле app.config, расположенном там, где находится exe, а не в папке пользователя AppData. Нет, не очень хорошо, но я использую его во время разработки, чтобы использовать одни и те же настройки от компиляции до компиляции (без нее они создают новые уникальные пользовательские папки с каждой компиляцией).Если вы планируете сохранить файл в том же каталоге, что и ваш исполняемый файл, вот хорошее решение, которое использует формат JSON :
источник
DEFAULT_FILENAME
, просто позвонитеsettings.Save(theFileToSaveTo)
; Будучи всеми заглавными буквами,DEFAULT_FILENAME
должен быть постоянным . Если вам нужно свойство для чтения и записи, создайте его и присвойте конструктору значениеDEFAULT_FILENAME
. Затемnull
укажите значение аргумента по умолчанию , проверьте это и используйте свое свойство в качестве значения по умолчанию. Это немного больше печатать, но дает вам более стандартный интерфейс.System.Web.Extensions.dll
если вы еще этого не сделали.Реестр запрещён. Вы не уверены, имеет ли пользователь, который использует ваше приложение, достаточные права для записи в реестр.
Вы можете использовать
app.config
файл для сохранения настроек уровня приложения (которые одинаковы для каждого пользователя, использующего ваше приложение).Я бы сохранял пользовательские настройки в файле XML, который сохранялся бы в изолированном хранилище или в каталоге SpecialFolder.ApplicationData .
Кроме того, начиная с .NET 2.0, можно сохранять значения обратно в
app.config
файл.источник
ApplicationSettings
Класс не поддерживает сохранение настроек в app.config файл. Это очень много задумано; приложения, работающие с должным образом защищенной учетной записью пользователя (например, Vista UAC), не имеют доступа на запись в папку установки программы.Вы можете бороться с системой с
ConfigurationManager
классом. Но тривиальный обходной путь заключается в том, чтобы зайти в конструктор настроек и изменить область настройки на «Пользователь». Если это вызывает затруднения (скажем, настройка важна для каждого пользователя), вы должны поместить свою опцию «Параметры» в отдельную программу, чтобы вы могли запросить запрос на повышение привилегий. Или отказаться от использования настроек.источник
Аргумент registry / configurationSettings / XML по-прежнему выглядит очень активным. Я использовал их все по мере развития технологии, но мой любимый основан на системе Threed в сочетании с изолированным хранилищем .
Следующий пример позволяет хранить объекты с именами свойств в файле в изолированном хранилище. Такие как:
Свойства могут быть восстановлены с использованием:
Это просто образец, не наводящий на мысль о передовой практике.
источник
Я хотел поделиться библиотекой, которую я построил для этого. Это крошечная библиотека, но большое улучшение (IMHO) по сравнению с файлами .settings.
Библиотека называется Jot (GitHub) . Вот старая статья The Code Project, которую я написал об этом.
Вот как вы можете использовать его для отслеживания размера и местоположения окна:
Преимущество по сравнению с файлами .settings: кода значительно меньше, и он намного менее подвержен ошибкам, поскольку вам нужно упомянуть каждое свойство только один раз .
В файлах настроек вам нужно упоминать каждое свойство пять раз: один раз, когда вы явно создаете свойство, и еще четыре раза в коде, который копирует значения туда и обратно.
Хранение, сериализация и т. Д. Полностью настраиваются. Когда целевые объекты создаются IoC контейнером , вы можете [подключить его] [], чтобы он автоматически применял отслеживание ко всем объектам, которые он разрешает, так что все, что вам нужно сделать, чтобы сделать свойство постоянным, - это нажать [Отслеживаемый] атрибут на это.
Он легко настраивается, и вы можете настроить: - когда данные сохраняются и применяются глобально или для каждого отслеживаемого объекта - как они сериализуются - где они хранятся (например, файл, база данных, онлайн, изолированное хранилище, реестр) - правила, которые могут отменить применение / постоянные данные для свойства
Поверьте мне, библиотека на высшем уровне!
источник
Простой способ - использовать объект данных конфигурации, сохранить его в виде файла XML с именем приложения в локальной папке и при запуске прочитать его обратно.
Вот пример для хранения позиции и размера формы.
Объект данных конфигурации строго типизирован и прост в использовании:
Класс менеджера для сохранения и загрузки:
Теперь вы можете создать экземпляр и использовать в событиях загрузки и закрытия формы:
И созданный XML-файл также доступен для чтения:
источник
c:\program files\my application
папке, поэтому сохранение настроек выдает ошибку. Вместо этого я пытаюсь сохранить XML-файл в AppData, но мне просто интересно, существует ли очевидный способ обойти эту проблему, поскольку этот подход, похоже, сработал для вас.Мне не нравится предложенное решение использования
web.config
илиapp.config
. Попробуйте прочитать свой собственный XML. Взгляните на файлы настроек XML - больше нет web.config .источник
Другие варианты, вместо использования пользовательского файла XML, мы можем использовать более удобный для пользователя формат файла: файл JSON или YAML.
Вы можете сохранить файл настроек в нескольких специальных папках (для всех пользователей и для каждого пользователя), как указано здесь Environment.SpecialFolder Enumeration и несколько файлов (только для чтения по умолчанию, для каждой роли, для каждого пользователя и т. Д.)
Если вы решили использовать несколько настроек, вы можете объединить эти настройки: Например, объединение настроек по умолчанию + BasicUser + AdminUser. Вы можете использовать свои собственные правила: последнее переопределяет значение и т. Д.
источник
«Значит ли это, что я должен использовать собственный XML-файл для сохранения настроек конфигурации?» Нет, не обязательно Мы используем SharpConfig для таких операций.
Например, если файл конфигурации такой
Мы можем получить такие значения
Он совместим с .NET 2.0 и выше. Мы можем создавать файлы конфигурации на лету и сохранить их позже.
Источник: http://sharpconfig.net/
GitHub: https://github.com/cemdervis/SharpConfig
источник
Насколько я могу судить, .NET поддерживает сохранение настроек с помощью встроенного средства настройки приложения:
источник
Иногда вы хотите избавиться от этих настроек, хранящихся в традиционном файле web.config или app.config. Вы хотите более детальный контроль над развертыванием записей настроек и отдельным дизайном данных. Или требуется включить добавление новых записей во время выполнения.
Я могу представить два хороших варианта:
Преимущество строго типизированной версии - строго типизированные имена и значения настроек. Нет риска смешивания имен или типов данных. Недостатком является то, что необходимо закодировать больше настроек, которые нельзя добавить во время выполнения.
Преимущество объектно-ориентированной версии заключается в том, что новые параметры могут быть добавлены во время выполнения. Но у вас нет строго типизированных имен и значений. Нужно быть осторожным со строковыми идентификаторами. Должен знать тип данных, сохраненный ранее при получении значения.
Вы можете найти код обеих полнофункциональных реализаций ЗДЕСЬ .
источник
Да, можно сохранить конфигурацию, но это в значительной степени зависит от того, как вы решите это сделать. Позвольте мне описать технические различия, чтобы вы могли понять, какие у вас есть варианты:
Во- первых, нужно различать, хотите ли вы использовать applicationSettings или AppSettings в вашем
*.exe.config
(он жеApp.config
в Visual Studio) файл - есть принципиальные различия, которые описаны здесь .Оба предоставляют разные способы сохранения изменений:
config.Save(ConfigurationSaveMode.Modified);
, где конфигурации определяется какconfig = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
).Properties.Settings.Default.Save();
) будет написано на каждый пользователь, хранятся в специальном месте (напримерC:\Documents and Settings\USERID\Local Settings\Application Data\FIRMNAME\WindowsFormsTestApplicati_Url_tdq2oylz33rzq00sxhvxucu5edw2oghw\1.0.0.0
). Как отметил в своем ответе Ханс Пассант , это связано с тем, что пользователь обычно имеет ограниченные права на программные файлы и не может писать в него, не вызывая приглашение UAC. Недостатком является то, что если вы добавляете ключи конфигурации в будущем, вам необходимо синхронизировать их с каждым профилем пользователя.Примечание. Как уже упоминалось в вопросе, существует третий вариант: если вы рассматриваете файл конфигурации как XML-документ, вы можете загрузить, изменить и сохранить его с помощью
System.Xml.Linq.XDocument
класса. Не обязательно использовать пользовательский файл XML, вы можете прочитать существующий файл конфигурации; для запроса элементов вы можете даже использовать запросы Linq. Я привел пример здесь , проверьте функциюGetApplicationSetting
там в ответе.Если вам требуется шифрование для защиты ваших значений, проверьте этот ответ.
источник
источник