. Net settings preserve, Інтеграція додатків і даних, Бази даних, статті

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


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


VB


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


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


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


C#


r.codenet.ru/?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 ви першим ділом переглядаєте його вміст і миттєво губитеся серед безлічі настроювальних секцій.


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


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


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


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


Web.config


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


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


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


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


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


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


WebConfigurationManager


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


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


WinAPI


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


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


Registry


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

Application.UserAppDataRegistry.SetValue
Application.UserAppDataRegistry.CommonAppDataRegistry

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


File store


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

Application.CommonAppDataPath
Application.UserAppDataPath

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


Team Work


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


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


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


r.codenet.ru/?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>

*

*