Файл g
Кожна веб-програма успадковує параметри налаштування з файлу machine.config та кореневого файлу web.config. Крім того, параметри можуть застосовуватися до окремих веб-застосунків. Наприклад, веб-програма може містити специфічний метод автентифікації, тип налагодження, мову за промовчанням або спеціальні сторінки повідомлень про помилки. Щоб зробити це, знадобиться додати до кореневої віртуальної папки своєї веб-додатку файл web.config. Для конфігурування окремих підкаталогів у веб-застосунку в них слід помістити додаткові файли web.config.
Важливо розуміти, що файл web.config у веб-застосунку не може перевизначати всі параметри у файлі machine.config. Деякі параметри цього файлу, такі як параметри моделі процесів, не можуть змінюватися для кожної програми окремо. Інші параметри, навпаки, специфічні для додатків. Це означає, що їх можна встановлювати у файлі web.config, який знаходиться у кореневому віртуальному каталозі веб-сайту, але не можна у файлах web.config, які розташовані в підкаталогах.
Весь вміст конфігураційного файлу ASP.NET знаходиться всередині кореневого елемента. Цей елемент містить елемент , який використовується для параметрів ASP.NET. Всередині є окремі елементи для кожного аспекту конфігурації. Також є елемент, який використовується для зберігання спеціальних параметрів, і елемент , що використовується для зберігання рядків підключення до баз даних, які використовуєте ви або на які покладаються засоби ASP.NET.
Нижче наведено вміст найпростішого файлу web.config, який виходить під час створення порожнього веб-сайту ASP.NET у Visual Studio:
Як і всі XML-документи, вміст файлу web.config чутливий до регістру символів. Коженпараметр використовує стиль Camel і починається з великої літери. Це означає, що записувати замість цього не допускається.
Конфігураційний файл для програм ASP.NET 3.5 має більш складну структуру через спосіб, яким ASP.NET 3.5 була випущена. По суті, ASP.NET 3.5 є комбінацією, яка складається з базової моделі ASP.NET 2.0, з середовищем CLR 2.0, і набору розширень. Як результат, кожна програма використовує файл web.config для підключення нових засобів. Однак у ASP.NET 4 такий підхід не застосовується, і додатки ASP.NET мають більш простий та зрозумілий вміст. Додаткові параметри налаштування були переміщені у файл machine.config та кореневий файл web.config, де їм саме місце.
Наслідування конфігурації
В ASP.NET використовується багаторівнева конфігураційна система, яка дозволяє застосовувати різні параметри до різних частин програми. Цей прийом вимагає створення всередині віртуального каталогу додаткових підкаталогів. Ці підкаталоги можуть містити власні файли web.config із додатковими параметрами налаштування. ASP.NET використовує успадкування конфігурації, завдяки якому кожен підкаталог автоматично отримує параметри налаштування батьківського каталогу.
Наприклад, розглянемо веб-запит http://localhost/A/B/C/MyPage.aspx, де А представляє кореневий каталог веб-додатку. Цей запит передбачає використання параметрів на багатьох рівнях:
Спочатку застосовуються параметри, що використовуються за замовчуванням, з файлу machine.config.
Далі застосовуються параметри з файлу web.config, що у кореневому каталозі комп'ютера. Цей файл web.config зберігається у тому самому каталозі Config, як і файл machine.config.
Якщо в кореневому каталозі додатка А є файл web.config, то наступнимизастосовуються параметри, зазначені у ньому.
Якщо в підкаталозі є файл web.config, тоді наступними застосовуються параметри, зазначені в цьому файлі.
Якщо в підкаталозі є файл web.config, тоді наостанок застосовуються параметри з нього.
Завдяки цьому на рівні підкаталогів може бути вказано лише невеликий набір параметрів, що відрізняються від інших параметрів веб-програми. Однією з причин використання в додатку безлічі підкаталогів є необхідність застосовувати параметри безпеки, що відрізняються. Файли, що потребують захисту, можуть бути поміщені в спеціальний каталог з файлом web.config, який визначає більш суворі параметри безпеки, ніж у кореневому віртуальному каталозі.
Якщо виникає конфлікт, параметри файлу web.config, що знаходиться у вкладеному каталозі, завжди перевизначають ті, що успадковані від батька. Однак є один виняток. Можна призначити спеціальні заблоковані розділи параметрів, які не можна змінювати. Цей прийом докладніше описаний у наступному розділі.
Якщо ви розробляєте веб-проект (а не безпроектний веб-сайт), до цього проекту будуть також включені файли web.Debug.config та web.Release.config. Ці файли призначені для перемикання між параметрами, що використовуються під час тестування веб-програми, та параметрами, які необхідні під час його розгортання у виробничому середовищі. Однак вони не дають жодного ефекту при запуску програми Visual Studio, оскільки в цьому випадку вони повністю ігноруються.
Використання елементів
Елемент є розширенням, що дозволяє визначати кілька груп параметрів налаштування в одному файлі конфігурації. Щоб визначити підкаталог або файл, до якого будуть застосованіпараметри налаштування потрібно використовувати атрибут path в елементі . Наприклад, у наступному файлі web.config елемент застосовується для створення двох груп параметрів налаштування - для поточного каталогу та для підкаталогу Secure:
Цей файл web.config, власне, грає роль двох конфігураційних файлів. Він призводить до такого ж результату, якби ви розділили параметри налаштування на два окремі файли web.config і помістили їх у підкаталог Secure.
В одному конфігураційному файлі може знаходитися скільки завгодно різних елементів. Однак елемент часто не використовується, оскільки набагато простіше керувати та оновлювати параметри конфігурації, коли вони розділені на окремі файли. Тим не менш, існує один сценарій, в якому елемент забезпечує функціональність, яку не вдасться отримати іншим способом. Це необхідно тоді, коли потрібно заблокувати специфічні параметри налаштування таким чином, щоб їх не можна було перевизначити.
Щоб отримати уявлення про роботу цієї технології, розглянемо наведений нижче приклад. У ньому визначено дві групи параметрів налаштування, для однієї з яких атрибутallowOverride дескриптора встановлюється false:
У цьому випадку перевизначити будь-які параметри налаштування в розділі не вдасться. Якщо ви спробуєте це зробити, ASP.NET згенерує необроблений виняток при запиті сторінки на веб-додаток.
Атрибут allowOverride елемента призначений в основному для компаній, що займаються веб-хостингом, яким потрібно захистити деякі параметри налаштування від зміни. У цьому випадку адміністратору доведеться модифікувати файл machine.config на веб-сервері та використовувати елемент для блокування різних розділів.
При блокуванні параметрів налаштування вфайлі machine.config можливі два варіанти: перший - заблокувати параметри відразу для всіх програм, опустивши в дескрипторі атрибут path, а другий - заблокувати параметри тільки для конкретної програми, вказавши в атрибуті path ім'я відповідної веб-програми.
Елемент містить всі конфігураційні параметри, що стосуються ASP.NET. Ці параметри відповідають за налаштування різних аспектів веб-програми та включають різні служби, такі як безпека, керування станом та трасування. Схема розділу фіксованою, тобто. змінювати структуру та додавати власні елементи не можна. Однак можна включати скільки завгодно конфігураційних розділів.
У таблиці нижче перераховані основні дочірні елементи, які можуть бути присутніми в описі їх призначення. Даний список далеко не повний і призначений для надання лише загальної картини про масштаби конфігурації ASP.NET:
Архітектура конфігураційного файлу є стандартом .NET, і програми іншого типу (наприклад, програми для Windows) також можуть використовувати файли конфігурації. Тому кореневий елемент не призначений для налаштування веб-програми. Натомість параметри веб-застосунку містяться всередині виділеного розділу .
Цей розділ містить параметри, які впливають на веб-сервер. Елемент усередині цього розділу використовується для реєстрації спеціальних обробників HTTP, а розділ – для реєстрації модулів HTTP.
Спеціальні параметри вводяться за допомогою елемента , який ідентифікує унікальне ім'я змінної (ключ) та її вміст (значення). Нижче наведено приклад додавання двох нових спеціальних параметрів налаштування:
Після додавання такої інформації .NET дозволяє надзвичайнолегко витягувати її у коді веб-сторінок. Все, що знадобиться - це просто використовувати класWebConfigurationSettings, який знаходиться в просторі імен System.Web.Configuration. Цей клас надає статичну властивість AppSettings, в якій міститься динамічно генерована колекція всіх доступних у поточному каталозі параметрів програми.
Наприклад, якщо клас сторінки ASP.NET, який посилається на колекцію AppSettings, знаходиться в http://localhost/MyApp/MyDirectory/MySubdirectory, то в колекції AppSettings, ймовірно, будуть міститися параметри налаштування трьох різних файлів web.config. Колекція AppSettings робить ієрархію параметрів безшовної для сторінки, яка її використовує.
Для використання класу WebConfigurationSettings спочатку необхідно імпортувати простір імен System.Web.Configuration, щоб мати можливість посилатися на цей клас, не вказуючи його довге уточнене ім'я:
Далі залишиться просто отримати необхідне значення на ім'я:
Нижче показано тестову веб-сторінку в дії:
В даному випадку при спробі отримати неіснуюче значення жодної помилки не виникає. Якщо є підозра, що це може стати джерелом проблем, тоді перед вилученням значення подбайте про перевірку щодо наявності нульового посилання.