Web config где находится visual studio
Обновлено: 07.07.2024
1. Приоритет поиска файла конфигурации
2. Описание узла файла конфигурации
Файл Web.config представляет собой файл XML, его корневой узел - <конфигурация>, общие подузлы в узле <конфигурация>: <configSections>, <appSettings>, <connectionStrings> и <system.web>. Среди них узел <appSettings> в основном используется для настройки информации о конфигурации приложений некоторых веб-сайтов, а узел <connectionStrings> в основном используется для настройки информации строки подключения к базе данных веб-сайта.
Узел <system.web> - это в основном некоторая конфигурация, когда сайт работает, его общие узлы следующие:
[2] узел <connectionStrings>
Узел <connectionStrings> в основном используется для настройки соединения с базой данных, мы можем добавить любое количество узлов в узел <connectionStrings>, чтобы сохранить строку соединения с базой данных, в будущем код будет динамически получен с помощью кода Значение узла для создания экземпляра объекта соединения с базой данных, чтобы после изменения информации о соединении с базой данных при ее развертывании нам нужно было только изменить конфигурацию здесь, без необходимости изменять программный код и повторное развертывание из-за изменений информации о соединении с базой данных.
Ниже приведен пример конфигурации узла <connectionStrings>:
В коде мы можем создать экземпляр объекта подключения к базе данных следующим образом:
Преимущество этого состоит в том, что, если база данных, используемая во время разработки, и база данных, использованная во время развертывания, несовместимы, вам нужно всего лишь отредактировать значение атрибута connectionString с помощью инструмента редактирования текста, такого как Блокнот.
Сначала настройте <customErrors> следующим образом:
Роль приведенного выше кода заключается в том, чтобы запретить доступ к любому текстовому файлу в каталоге IPData.
Затем создайте новую страницу, добавьте гиперссылку на страницу, ссылку на файл IPData.txt в каталоге, код выглядит следующим образом:
Эффект запуска этой страницы заключается в следующем:
Текущая конфигурация узла <customErrors> в файле web.config выглядит следующим образом:
Если есть страницы 403.htm и 404.htm, после нажатия гиперссылки появится следующий эффект:
Из приведенного выше рисунка видно, что когда атрибут режима узла <customErrors> имеет значение «Вкл.», поскольку доступ ко всем txt-файлам в папке IPData запрещен, он переходит к Настраиваемая страница запроса без разрешения, а именно 403.htm.
[9] узел <pages>
Ниже приведен пример узла конфигурации:
Храня приведенный выше код в папке App_Code, мы можем использовать его прямо в проекте.
Мы используем пример, чтобы продемонстрировать, как использовать этот общий класс для установки web.config. Создайте новую страницу aspx, следующий код администратора:
При написании фонового кода иногда может потребоваться добавить ссылку на dll (System.Configuration), где находится класс операций чтения-записи файла конфигурации, следующим образом:
Ниже приведен код:
Ниже приводится работающий интерфейс:
Мы заполняем следующую информацию в форме выше:
Предположим, что содержимое соответствующих узлов файла web.config выглядит следующим образом:
Содержимое файла после нажатия кнопки «Изменить» выглядит следующим образом:
Элемент configuration/runtime/assemblyBinding/dependentAssembly, который идентифицирует сборку Microsoft.VisualStudio.Enterprise.ASPNetHelper, управляющую профилированием. Элемент dependentAssembly содержит два дочерних элемента: assemblyIdentity и codeBase.
Элемент configuration/system.web/compilation, который определяет шаг компиляции пост-обработки профилировщика для целевой сборки.
Два элемента add, которые задают расположение средств профилирования, добавляются в раздел configuration/appSettings.
Рекомендуется создать копию исходного файла web.config, который можно использовать для восстановления конфигурации приложения.
Добавление сборки ASPNetHelper как элемента configuration/runtime/assemblyBinding/dependentAssembly
При необходимости добавьте элемент runtime как дочерний элемент элемента configuration; в противном случае переходите к следующему шагу.
У элемента runtime нет атрибутов. Элемент configuration может иметь только один дочерний элемент runtime.
При необходимости добавьте элемент assemblyBinding как дочерний элемент элемента runtime; в противном случае переходите к следующему шагу.
Элемент runtime может иметь только один элемент assemblyBinding.
Добавьте следующее имя и значение атрибута в элемент assemblyBinding:
Добавьте элемент dependentAssembly как дочерний элемент элемента assemblyBinding.
Элемент dependentAssembly не имеет атрибутов.
Добавьте элемент assemblyIdentity как дочерний элемент элемента dependentAssembly.
Добавьте следующие имена и значения атрибутов в элемент assemblyIdentity:
Добавьте элемент codeBase как дочерний элемент элемента dependentAssembly.
Добавьте следующие имена и значения атрибутов в элемент codeBase:
| Имя атрибута | Значение атрибута |
|---|---|
| version | 10.0.0.0 |
| href | PathToASPNetHelperDll |
PathToASPNetHelperDll — это URL-адрес файла Microsoft.VisualStudio.Enterprise.ASPNetHelper.dll. Если файл Visual Studio установлен в папку по умолчанию, значение href должно быть следующим: C:/Program%20Files/Microsoft%20Visual%20Studio%202010.0/Common7/IDE/PrivateAssemblies/Microsoft.VisualStudio.Enterprise.ASPNetHelper.DLL .
Добавление шага пост-обработки профилировщика в элемент configuration/system.web/compilation
При необходимости добавьте элемент system.web как дочерний элемент элемента configuration; в противном случае переходите к следующему шагу.
У элемента system.web нет атрибутов. Элемент configuration может иметь только один дочерний элемент system.web.
При необходимости добавьте элемент compilation как дочерний элемент элемента system.web; в противном случае переходите к следующему шагу.
Элемент system.web может иметь только один дочерний элемент compilation.
Удалите существующие атрибуты из элемента compilation и добавьте следующее имя и значение атрибута:
Добавление параметров расположения профилировщика в элемент configuration/appSettings
При необходимости добавьте элемент appSettings как дочерний элемент элемента configuration; в противном случае переходите к следующему шагу.
У элемента appSettings нет атрибутов. Элемент configuration может иметь только один дочерний элемент appSettings.
Добавьте элемент add как дочерний элемент элемента appSettings.
Добавьте следующие имена и значения атрибутов в элемент add:
Добавьте еще один элемент add как дочерний элемент элемента appSettings.
Добавьте следующие имена и значения атрибутов в этот элемент add:
| Имя атрибута | Значение атрибута |
|---|---|
| key | Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrTools |
| value | PerformanceToolsFolder |
PerformanceToolsFolder — это путь к исполняемым файлам профилировщика. Сведения о пути к средствам профилирования см. в статье Указание пути к программам командной строки средств профилирования.
Расположение файла web.config
Файл web.config должен постоянно находиться в развертывании, у этого файла должно быть правильное имя, и файл должен быть в состоянии настроить нормальный запуск сайта. Никогда не удаляйте файл web.config из развертывания в рабочей среде.
Чтобы веб-пакет SDK не преобразовывал файл web.config , используйте свойство <IsTransformWebConfigDisabled> в файле проекта:
Следующий файл web.config опубликован для автономного развертывания.
Значение false свойства InheritInChildApplications указывает, что параметры, заданные в элементе <location> , не наследуются приложениями, которые находятся во вложенном каталоге приложения.
Когда приложение развернуто в службе приложений Azure, путь stdoutLogFile задан как \\?\%home%\LogFiles\stdout . Путь сохраняет журналы stdout в папке LogFiles , расположение которой автоматически создается службой.
Атрибуты элемента aspNetCore
Необязательный строковый атрибут.
Аргументы для исполняемого файла, указанного в атрибуте processPath .
Дополнительный логический атрибут.
Если значение равно true, страница 502.5 — ошибка процесса подавляется и страница в файле web.config с кодом состояния 502 имеет более высокий приоритет.
Дополнительный логический атрибут.
Если значение равно true, маркер безопасности отправляется дочернему процессу, прослушивающему порт %ASPNETCORE_PORT% , как заголовок MS-ASPNETCORE-WINAUTHTOKEN каждого запроса. Этот процесс вызывает CloseHandle по этому маркеру безопасности каждого запроса.
Необязательный строковый атрибут.
Указывает модель размещения — внутри процесса ( InProcess / inprocess ) или вне процесса ( OutOfProcess / outofprocess ).
Необязательный целочисленный атрибут.
Указывает число экземпляров процесса, заданное в параметре processPath , которое может появиться для каждого приложения.
†Для внутрипроцессного размещения существует ограничение: 1 .
Параметр processesPerApplication не рекомендуется. Этот атрибут будет удален в будущем выпуске.
Обязательный строковый атрибут.
Необязательный целочисленный атрибут.
Указывает количество сбоев за минуту, которыми может завершиться процесс, указанный в processPath . Если этот предел превышен, модуль останавливает запуск процесса на оставшуюся часть минуты.
Не поддерживается для внутрипроцессного размещения.
Необязательный атрибут timespan.
Не применяется к внутрипроцессному размещению. Для внутрипроцессного размещения модуль ожидает, пока приложение не обработает запрос.
Допустимые значения для сегментов минут и секунд в строках находятся в диапазоне 0–59. Значение 60 для минут и секунд приведет к ошибке 500 — внутренняя ошибка сервера.
Необязательный целочисленный атрибут.
Длительность ожидания модуля в секундах, пока произойдет правильное выключение исполняемого файла при обнаружении файла app_offline.htm .
Необязательный целочисленный атрибут.
Время в секундах, которое модуль ожидает, пока запустится процесс прослушивания порта исполняемого файла. Если этот предел превышен, модуль завершает процесс.
Внутрипроцессное размещение. Процесс не перезапускается, и параметр rapidFailsPerMinute не используется.
Размещение вне процесса. Модуль пытается перезапустить процесс при получении нового запроса и будет продолжать пытаться перезапустить процесс для последующих входящих запросов, если не удается запустить приложение определенное в атрибуте rapidFailsPerMinute количество раз за последнюю минуту.
Значение 0 (ноль) не считается бесконечным временем ожидания.
Дополнительный логический атрибут.
Если значение равно true, stdout и stderr для процесса, указанного в атрибуте processPath , перенаправляются к файлу, заданному в атрибуте stdoutLogFile .
Необязательный строковый атрибут.
Указывает относительный или абсолютный путь к файлу, для которого регистрируются stdout и stderr из процесса, указанного в processPath . Относительные пути задаются относительно корневого каталога веб-сайта. Любой путь, начинающийся с . , относится к корневому каталогу веб-сайта, а все остальные пути рассматриваются как абсолютные пути. Все папки, указанные в пути, создаются модулем при создании файла журнала. С помощью разделителей подчеркивания метка времени, идентификатор процесса и расширение файла ( .log ) добавляются к последнему сегменту пути журнала stdoutLogFile . Если в качестве значения задано значение .\logs\stdout , например, журнал stdout сохраняется как stdout_20180205194132_1934.log в папке logs с датой 5 февраля 2018 г. в 19:41:32 с идентификатором процесса 1934.
Настройка переменных среды
Переменные среды для процесса можно указать в атрибуте processPath . Укажите переменную среды с дочерним элементом <environmentVariable> элемента коллекции <environmentVariables> . Переменные среды, установленные в этом разделе, имеют приоритет над переменными системной среды.
Вместо установки среды напрямую в web.config можно включить свойство <EnvironmentName> в профиль публикации ( .pubxml ) или файл проекта. При этом подходе во время публикации проекта среда задается в файле web.config :
Установите только переменную среды ASPNETCORE_ENVIRONMENT для Development на серверах промежуточных процессов и тестирования, которые недоступны для ненадежных сетей, таких как Интернет.
Трансформация web.config-файла
В этой статье я начну с первого важного инструмента — с трансформации web.config-файла. Если вы до сих пор не знакомы с этой техникой, то данный раздел вам обязательно стоит прочесть.
Трансформация появилась вместе с Visual Studio 2010 и сразу же решила огромное количество проблем, связанных с разными настройками для DEV и PROD-окружения. При этом, правила, по которым выполняется трансформация, чрезвычайно простые и гибкие.
Вы наверняка замечали, что, начиная с VS 2010, файл web.config внезапно начал отображаться в дереве проекта как контейнер, внутри которого теперь лежат два новых файла web.release.config и web.debug.config. Это и есть файлы, в которых настраивается трансформация основного web.config-файла. Вы можете вообще не использовать эти два файла и работать с основным web.config, как с единственным, и это не повлечёт за собой никаких проблем. Но будет лучше постигнуть этот дзен, чтобы впоследствии практиковать его всегда и с умом.
Изучая, как работает трансформация, самое главное — чётко усвоить две главные вещи при её настройке:
1. Трансформация работает только при публикации (publish) проекта
2. Файлы web.debug.config и web.release.config не заменяют оригинальный web.config, а изменяют (трансформируют) его
Казалось бы, что первый пункт накладывает серьёзные ограничения на использование трансформации в разработке. И действительно, какой от неё может быть толк, когда вы разрабатываете проект, например, под IIS Express, то есть, без публикаций? Но на самом деле, это не проблема, однако я затрону этот момент позже.
Что касается второго пункта, то это обычная ошибка тех, кто впервые столкнулся с трансформацией, включая меня: сперва я решил, что при публикации происходит подмена файла web.config на соответствующий release/debug-файл. Разумеется, первая же публикация заставила меня прочесть мануал внимательно, потому что это работает совсем не так.
Работает же это следующим образом: в файлах трансформации указывается как именно должен быть изменён оригинальный web.config при публикации в соответствующей конфигурации. Не будем далеко ходить и рассмотрим стандартный пример. Автосоздаваемый файл web.release.config по умолчанию уже содержит одну стандартную директиву для трансформации. Вот его листинг (с удалёнными комментариями):
Для начала, обратите внимание на ключевой момент: у элемента configuration определяется префикс xdt для неймспейса XML-Document-Transform. В этом неймспейсе объявлены два атрибута, с помощью которых и определяется трансформация: Locator и Transform. Атрибут Locator определяет, что именно вы хотите изменить в конфигурационном файле, а атрибут Transform указывает как вы хотите это сделать. В приведённом примере используется только Transform — его значение говорит нам, что нужно в элементе compilation оригинального файла web.config удалить атрибут debug (вместе с его значением, разумеется).
Вернёмся к нашему примеру. При публикации проекта в Release-конфигурации из финального web.config-файла будет убран атрибут debug в элементе configuration/system.web/compilation, причём, независимо от того, какое у него было значение и был ли он там вообще. Обратите внимание, что в примере отсутствует атрибут Locator, потому что трансформация явно задана для конкретного элемента config-файла. Но с помощью атрибута Locator можно более гибким способом указывать элементы web.config-файла для трансформации, в частности, используя XPath-выражения или задавая явное соответствие значений атрибутов. Вот ещё пример:
В этом примере в исходном web.config будет проведён поиск настройки с ключом key1 (это указано через XPath в Locator), и если такая будет найдена, то она будет полностью заменена
(значение Replace атрибута Transform) на настройку из файла с трансформацией. Значение Condition атрибута Locator содержит XPath-выражение, применяемое к тому элементу config-файла, в котором оно определено, при этом сам элемент автоматически становится текущим для XPath-выражения. Кроме Condition в атрибуте Locator можно указать значение XPath — он отличается только тем, что XPath-выражение будет рассмотрено в глобальном контексте.
В этом примере мы добавляем в итоговый web.config целую секцию настроек customErrors (кстати, весьма полезная и часто используемая секция для настройки поведения веб-приложения в случае возникновения ошибки). Замечу, что, используя значение Insert атрибута Transform, мы предполагаем отсутствие этой секции в оригинальном web.config. Если же она там есть, то нам следует использовать Replace вместо Insert.
В итоге мы имеем мощный инструмент, с помощью которого мы можем на лету при публикации проекта изменять web.config-файл самыми разными способами, а именно: изменять, удалять или добавлять отдельные элементы либо атрибуты элементов (а также целые группы элементов) и менять значения любых атрибутов у любых элементов. Это позволяет нам избавиться от постоянного комментирования настроек в web.config-файле или регулярной его подмены на «тестовый»/«боевой» при отладке. Полный список значений атрибутов трансформации с примерами использования вы можете найти в MSDN.
Если говорить о реальном использовании трансформаций в моих проектах, то из всех настроек web.config-файла чаще всего затрагиваются следующие:
1. Connection Strings или, другими словами, все настройки подключения к базам данных. Это касается и самих connection string и настроек всех ORM-фреймворков.
2. Настройки секции appSettings. Все настройки переводятся из режима разработки/отладки в режим боевого использования.
3. Настройки обработки ошибок веб-приложения — секция /<system.web>/ в примере выше. При разработке и тестировании лично для меня предпочтительнее видеть все ошибки с текстом и stack trace сразу, а не быть перекинутым на красивую страницу-заглушку. Разумеется, для боевого приложения это неприемлемо.
4. Настройки trace/log/debug. Кроме упомянутой выше настройки /> из web.config вычищаются все настройки, связанные с отладкой и трейсом (либо оставляются, но выключаются). А настройки лога переводятся из параноидального режима в рабочий.
Разумеется, это не полный перечень — всё зависит от конкретного проекта. Но именно эти настройки затрагиваются трансформациями почти во всех случаях.
Что же касается разработки с использованием IIS Express, при которой публикации не происходят, то, как я уже говорил, это не является проблемой для использования трансформаций. Я довольно часто разрабатываю веб-приложения с использованием IIS Express (то есть, без публикации на реальном веб-сервере), и поступаю довольно просто: оригинальный web.config-файл содержит все необходимые настройки в DEV-варианте, а трансформации задаются только в web.release.config. То есть, оригинальный web.config, по сути, выполняет роль web.debug.config-файла.
Итак, Visual Studio даёт нам возможность гибко управлять работой приложения в DEV и PROD окружениях, не внедряясь при этом в код, вёрстку или настройки с различными костылями или заглушками. Если вы до сих пор ещё не владеете этой техникой, то этот пробел необходимо срочно закрыть. В следующих статьях — о минификации, бандлах, скриптах, DEBUG и как это правильно использовать.
Читайте также: