.Net settings preserve

У середовищі. Net існує рекомендований механізм збереження параметрів програми для відновлення їх при наступних запусках додатка. Іншими словами конфігураційні файли тепер можна без зусиль прочитати засобами. Net, працюючи з ними за єдиною схемою. Вся райдужна картина затьмарюється одним моментом, ви без праці можете прочитати або зберегти будь-яке значення якщо ви знаєте який саме інтерфейс потрібно використовувати в даний момент. У середовищі. Net їх утворилося непристойне безліч. Без попередньої підготовки даний матеріал не сприймається на одному подиху і вимагає додаткового опрацювання для вибору оптимального механізму роботи. Тому я привожу короткий огляд всіх засобів роботи для бажаючих краще її використовувати.


Послідовне розповідь починається з документації, яку студія підсовує незалежно від бажання розробнику, і далі по тексту всі можливі методи роботи з налаштуваннями:


VB


Почавши роботу з настройками через дизайнер налаштувань проекту ви першим ділом, по не зрозумілим на те причин, потрапляєте в розділи документації присвячені мові VisualBasic. Даний розділ постає перед вами не залежно від того, в якій мові ви ведете розробку і які проекти в включені в поточний солюшін. На цей упор в демонстрації технології можна зробити знижку з урахуванням того, що технологія роботи з налаштуваннями додатків є між мовною, проте це не так. Отримуючи перші відомості про механізми завантаження і отримання значень, а також їх збереження з додатка досить різна.


http://r.codenet.ru/?http://msdn.microsoft.com/en-us/library/bc6ws923.aspx


З даних розділів документації утворюється загальна архітектура і механізми роботи з налаштуваннями притаманні всім інтерфейсам. Ставати зрозуміло, що механізм роботи з налаштуваннями з VB є стандартним і, мабуть, був розроблений спеціально для цього середовища. Прибираючи тим самим всі хитрі методи роботи з файлами, які було необхідно використовувати до цього. Саме з Бейсіка зручно додати налаштування і видалити їх з проекту використовуючи дизайнер, як ніколи раніше. Крім того, доступ з середовища виконання до параметрів зводитися до простого зверненням об’єкта My.Settings без будь-яких додаткових заворотів. Збереження та перезавантаження параметрів так само досягається шляхом виклику My.Settings.Save (), My.Settings.Reload (). Загалом ніяких проблем. А ось повна картина роботи з параметрами ставати дійсно докладної якщо ви звернетеся до документації по C # розділу Налаштування.


C#


http://r.codenet.ru/?http://msdn.microsoft.com/en-us/library/aa730869%28VS.80%29.aspx


Необхідно пам’ятати про те, що налаштування розділяються на дві області: користувача і додатки. Кожна область має свої специфічні особливості відображають механізми роботи з ними. Крім цього, налаштування потрапили в додаток з конфігураційних файлів не зчитуються безпосередньо з app.config наявного в директорії з програмою, а проходять додаткове об’єднання з файлами налаштувань користувача. Ці специфічні для користувача файли зберігаються в% APPDATA% [company] [product] [version] user.config, а так само в Local SettingsApplication Data [company] [product] [version] user.config.


Доступ до змінних з C # здійснюється через namespace Properties. Читання і установка змінної проводитися шляхом звернення до Properties.Settings.Default.myName значенням. Запис змінених налаштувань викликом методу Save () в об’єкта Properties.Settings.Default.Save ().  


WebServices<


Вся плутанина починається тоді, коли ви створюєте проект Вебсервіс і намагаєтеся задати параметри звичним для вас способом. Працюючи через дизайнер налаштувань, створені вами зміни потрапляють в файли Settings.settings проекту, замість покладеного Web.config. Але і це не така велика проблема в порівнянні з великим вибором і заплутаними схемами роботи з налаштуваннями пропоновані для роботи. Ось короткі зауваження:


По-перше, використовуючи веб сервіс студія всіма силами бажає запропонувати вам працювати за старою схемою і у неї це добре виходить. Ви без праці зберігаєте налаштування там, де вони не повинні бути, а так само без праці отримуєте їх значення. Крім того можете створити простий додаток працює за правилами локальних форм і підключити його до основного веб додатком. Тим самим добившись поганих результатів.


По-друге, розуміючи що настроювання повинні бути збережені у файлі web.config ви першим ділом переглядаєте його вміст і миттєво губитеся серед безлічі настроювальних секцій.


Ну і нарешті, по-третє: в документації представлені різні методи роботи з налаштуваннями веб сервісів, деякі з яких вже рекомендується не використовувати.


http://r.codenet.ru/?http://msdn.microsoft.com/en-us/library/ms180994.aspx


Інші ж розділи з цього питання просто помічені як не безпечні і лише підходять для ознайомлення з технологією.


http://r.codenet.ru/?http://msdn.microsoft.com/en-us/library/system.configuration.configurationsettings%28VS.71%29.aspx


Web.config


Налаштування файлу web.config описані в документі про ASP.NET Configuration Settings.


http://r.codenet.ru/?http://msdn.microsoft.com/en-us/library/b5ysx397%28VS.80%29.aspx


http://r.codenet.ru/?http://msdn.microsoft.com/en-us/library/6hy1xzbw%28VS.80%29.aspx


Важливою особливістю роботи конфігураційних файлів для вебу є просунутий, у порівнянні зі стандартними додатками, механізм успадкування налаштувань. Основний файл настройок міститься в папці systemrootMicrosoft.NETFrameworkversionNumberCONFIGWeb.config. Всі значення цього файлу можуть бути перезаписані новими конфігураційних файлом знаходяться в робочій папці. У теж час всі файли знаходяться в робочих папках так само можуть бути перезаписані конфігураційними файлами знаходяться за рівнем нижче в дочірніх папках.


За замовчуванням створений конфігураційний файл у проекті нового Вебсервіс містить мало інформації. Документації по цьому розділу в мене не вийшло знайти, проте якщо вам необхідно довідатися всі можливі параметри налаштування і призначення кожної секції вам знадобиться переглянути основний файл конфігурацій. Він знаходитись у папці systemrootMicrosoft.NETFrameworkversionNumberCONFIG *. Наприклад для того щоб дізнатися що ж представляє із себе загадкова секція. Необхідно відкрити machine.config, дізнатися тип однойменної секції в атрибуті type = “System.Configuration.AppSettingsSection” після чого можна відкрити розділ документації по конкретному розділу. Таким чином пробігшись по всьому значущим полях ми отримуємо уявлення про правила роботи з налаштуваннями програми під веб.


http://r.codenet.ru/?http://msdn.microsoft.com/en-us/library/system.configuration.appsettingssection.aspx


WebConfigurationManager


Що ж стосується роботи з Вебсервіс, то скажу лише що необхідно використовувати клас WebConfigurationManager. Наступною посиланням можна подивитися приклад роботи. Там же зазначено що це переважний спосіб роботи з налаштуваннями для веб додатків, однак для клієнтських програм спілкуються з даним сервісом необхідно вибрати клас ConfigurationManager.


http://r.codenet.ru/?http://draft.blogger.com/%20http://msdn.microsoft.com/en-us/library/system.web.configuration.webconfigurationmanager%28VS.80%29.aspx  


WinAPI


Ще один метод роботи з файлами налаштувань, з’явився тут заодно. Не використовуйте його при роботі під. Net


http://r.codenet.ru/?http://msdn.microsoft.com/en-us/library/ms725501%28VS.85%29.aspx  


Registry


Збереження налаштувань в реєстр ще один спосіб зберегти параметри програми між перезапуск. Однак даний метод лешен механізму спадкування.

Application.UserAppDataRegistry.SetValue
Application.UserAppDataRegistry.CommonAppDataRegistry

http://r.codenet.ru/?http://msdn.microsoft.com/en-us/library/system.windows.forms.application.userappdataregistry.aspx  


File store


Збереження даних на диску з подальшим використанням, рекомендується робити по цьому шляху:

Application.CommonAppDataPath
Application.UserAppDataPath

http://r.codenet.ru/?http://msdn.microsoft.com/en-us/library/system.windows.forms.application.userappdatapath.aspx


Team Work


Одне питання, який я залишив на останок – це спільна робота в проекті. Як би не здалося на перший погляд це сильно пов’язано з розглянутої темою і в першу чергу зачіпає використання загальних персоналізація налаштувань для кожної машини розробника.


Ми використовуємо різні системи контролю версій забезпечують синхронізацію коду між розробниками. В результаті чого ми маємо абсолютно ідентичні копії проекту на всіх машинах. Одночасно нам потрібно забезпечити індивідуальні налаштування і строчки з’єднання з базою даних, для конкретної середовища в якій працює програміст з його аутентифікаційні даними. Робити це можна по-старому – міняючи вміст проектних файлів для конкретних потреб. Однак краще скористатися конфігураціями керовані через ConfiguarationManager (або його веб версію).


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


http://r.codenet.ru/?http://msdn.microsoft.com/en-us/library/ms178685.aspx


Для прозорого підключення даного файлу до проекту скористаємося механізмом успадкування пропонованого за замовчуванням. Так як К ASP не пропонує гнучкої схеми спадкування нам доведеться виключити файл Web.config з репозиторія файлів перейменувавши його в Web.default.  

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*