Просмотров: 1110 - Заполнять:
SolarWind - 27.08.2009 14:59:57
Начну издалека, как я до сегодняшнего дня работал с конфигурационными файлами приложения. Еще в давние времена, когда я только начинал свой трудовой путь программиста и шло активное освоение, тогда уже .NET Framework 1.1, в один прекрасный момент встал вопрос о способе хранения конфигурационных данных приложения. Быстро поняв, что INI файлы больше не рулят, был освоен метод хранения конфигурации в XML файле, а точнее app.config. C тех пор технология для меня не сильно изменилась, добавляем в проект новый item - Application Configuration File прям в нем ручками добавляем тег <appSettings></appSettings> и в него начинаем накидывать теги для хранения параметров конфигурации <add key="" value=""/>. С выходом .NET Framework 2.0 изменилось только то, что на помощь пришел класс ConfigurationManager. На стороне приложения создавался класс что-то наподобие:
GeSHi: C#
using System;
using System.Collections.Generic;
using System.Text;
using System.Configuration;
namespace TestApp
{
internal class Config
{
public static string TestConfigValue;
static Config()
{
TestConfigValue = ConfigurationManager.AppSettings["TestConfigValue"];
}
public static void Save()
{
Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
config.AppSettings.Settings["TestConfigValue"].Value = TestConfigValue;
config.Save(ConfigurationSaveMode.Modified);
}
}
}
Добавлено за 0.007 секунд, используя GeSHi 1.0.8.2
Данного функционала мне хватало за глаза, тут и доступ к любым параметрам конфигурации из практически любой части программы и сохранение параметров конфигурации и простота реализации.
И вот я решил решил серьезно заюзать ClickOnce, для непосвященных - это технология развертывания приложения с диска, сетевой шары, сети (протоколы http и ftp), но самое замечательное - это автоматическое обновление приложения. Думаю, что не надо объяснять, когда у тебя приклад уже стоит на 20-30 компьютерах пользователей и тут в нем обнаруживается мелкая бага, работать не мешает, но при определенных действия пользователя все летит к чертям или внезапно изменяется формат входных данных. Поправить программу это одно дело, а вот заново ее распространить, да никого не забыть (отпуска, декреты, миграция по должностям конечных пользователей). Короче, такой, маленький ад. Еще одна незаменимая способность ClickOnce - для запуска установки не нужны административные права. Если организация очень большая (а у меня она просто огромная) и пользователи не являются локальными администраторами, для установки нового приложения нужно либо поднять админов которые пропишут тебя, как администратора на машине конечного пользователя (при одно-двухкратном развертывании катит), либо сдвинуть отдел тех. обеспечения, которые твой инсталлер закатают в msi и через групповую политику ActiveDirectory раздадут на машины конечных пользователей. С приходом ClickOnce все это стало историей, сейчас достаточно разослать письмо с ссылкой на инсталлер, находящийся в intranet под управлением IIS и короткой инструкцией по установке - "Соглашаться на все, о чем Вас спросят". В довершение всему, при перекомпиляции и deploy все пользователи гарантировано получат новую версию при следующем перезапуске. Счастье есть!
Итак, вернемся к нашим баранам, а вернее конфигурации приложения. Методом научного тыка было выяснено, что при деплое новой версии приложения на сервер, после того, как оно разворачивается на стороне пользователя файл конфигурации доблестно затирается либо моими значениями по умолчанию, либо моими тестовыми настройками, что нередко приводит к падению приклада (например путь для объекта FileSystemWatcher настроенный на мой путь не находит его у пользователя и при активации валит приложение). После непродолжительного гугления решение было найдено.
Как оказалось со времен .NET Framowork 1.1 в этом направлении технологии далеко продвинулись, конфигурация теперь может подразделяться на блоки: секция настроек пользователя и приложения, файл конфигурации теперь можно можно создавать непосредственно из VS и статичный класс теперь генерится автоматически. Но проблему с затиранием настроек пользователя при использовании ClickOnce в явном виде это не решает, но есть красивый обходной путь. Дело в том, что у базового класса генерируемого студией класса конфигурации - System.Configuration.ApplicationSettingsBase есть замечательный метод Upgrade(). Основная его задача это найти предыдущую версию файла конфигурации секции <userSettings> (тут небольшое отступление, при обычном развертывании copy и ClickOnce поведение у этой секции разное, подробности ищите в сети) и данные из нее записать в новый файл конфигурации. Остается дело за малым определить момент когда же у нас появляется новая конфигурация, т.е. отследить момент нового развертывания. Как оказалось прямых способов для этого нет и вот тут люди заюзали гениальность простоты.
Финт ушами заключается в следующем, нужно объявить новый параметр конфигурации, скажем с именем UpdateRequired, типа bool и значением по умолчанию "true" - это важный момент.
А в коде запуска приложения написать небольшой вызов:
GeSHi: C#
if (Properties.Settings.Default.UpdateRequired)
{
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.UpdateRequired = false;
}
Добавлено за 0.004 секунд, используя GeSHi 1.0.8.2
Итого, при новом развертывании и запуске приложения, конфигурация у нас будет заполнена значениями по умолчанию, т.е. свойство UpdateRequired примет значение - true, при активизации приложения мы это дело отследим, вызовем Properties.Settings.Default.Upgrade();, который перетянет параметры предыдущей версии в текущую, а флаг UpdateRequired мы выключим навсегда или по крайней мере до следующего развертывания или переинсталяции приложения.
