Конфигурации программы что это

Анатомия приложений ASP.NET

Разрабатывая приложения, можно столкнуться с ситуацией, когда некоторые значения не следует сохранять в листинге исходного кода программы, а эти значения зависят от той среды, где приложение исполняется. В случае сохранения этих настроек в исходном коде, приложение пришлось бы перекомпилировать всякий раз, когда оно переносится в другую среду, например, на другой компьютер .

Поэтому очень часто такие значения выносят за рамки исходного кода программы и сохраняют их во внешнем файле, который впоследствии можно изменить – файл конфигурации.

Исторически сложилось, что конфигурирование приложения — одна из наиболее классических задач, с которой сталкиваются разработчики приложений. Эта задача не специфична только для веб-приложений и решается в различных платформах по -разному.

В более ранних инструментах разработки приложений не содержалось встроенных средств для работы с настройками приложения, поэтому разработчикам каждый раз приходилось этот механизм разрабатывать заново. Формат настроек не был стандартизирован и каждый разработчик хранил в том формате, в котором считал нужным (например, в текстовом файле или в бинарном файле с собственной структурой). Подобный подход создавал ряд неудобств при разработке и использовании приложений. При разработке приложений приходилось постоянно возвращаться к вопросу о том, как хранить настройки приложения. При использовании приложения никогда не было стандартизированного формата конфигурационного файла, который можно использовать.

4 Что такое платформа и конфигурация

Платформа . NET Framework решает этот вопрос – в рамках платформы существует стандартный способ хранения конфигурации. В качестве формата для хранения настроек используется формат XML . Использование XML в качестве формата файла конфигурации обладает рядом преимуществ:

• он имеет иерархическую структуру, что, несомненно, удобно для хранения настроек приложения;
• файл XML, по сути, является текстовым файлом, что означает, что настраивать приложения .NET можно используя любой текстовой редактор.

Все конфигурационные файлы в рамках платформы . NET имеют расширение «.config». Например, для настройки веб-приложений используются файлы » web .config», а для настольных – » app .config».

Существует целая иерархия файлов конфигурации. Схема хранения файлов настроек показана ниже.

Система конфигурации . NET Framework разделена на две части – глобальные настройки и настройки приложения. Настройки, заданные в глобальных файлах конфигурации доступны для каждого приложения, т.е. глобальные настройки наследуются в каждом приложении.

На уровне приложения определяется главный файл конфигурации (он расположен в корневой папке приложения), в котором задаются основные настройки приложения. Для каждой подпапки в рамках проекта может быть определен собственный файл конфигурации. В этом случае для этой подпапки существует собственная конфигурация , которая наследуется из основного файла конфигурации и уточняется файлом конфигурации в данной папке. Такая иерархия позволяет определить глобальные настройки и постепенно, где это необходимо, уточнять их.

Что такое «платформа» программы, «редакция», «конфигурация» и «релиз»

Глобальные файлы настроек расположены в папке «C:WindowsMicrosoft.NETFramework*версия+CONFIG». Как видно из приведенной выше схемы в этой папке содержаться два файла – machine.config и web .config. Оба этих файла содержат конфигурационные настройки и имеют идентичный формат.

Разница этих файлов заключается в том, что параметры, определенные в файле «machine.config» нельзя переопределить на уровне приложения, а параметры, определенные в файле » web .config» можно переопределять на любом уровне иерархии. Например, давайте рассмотрим параметр , который отвечает за конкурентный доступ к веб-сервисам на основе платформы WCF.

Если этот параметр определить в глобальном файле » web .config», то он будет доступен для каждого приложения. При этом нет необходимости определять его для каждого приложения – он уже определен. Однако, если требуется изменить этот параметр для конкретного приложения, то это можно легко сделать переопределив этот параметр в файле » web .config» для приложения. Однако, если переместить определение этого параметра из глобального файла » web .config» в глобальный файл «machine.config», то переопределить параметр на уровне приложения уже будет нельзя.

Возможность такого «жесткого» задания конфигурационных параметров позволяет явным образом задавать политики сервера, в рамках которых исполняются множество приложений. При этом каждое приложение не сможет установить настройки сервера так, как ему это необходимо.

Как уже было сказано ранее, конфигурационные файлы построены на базе формата XML . Пример конфигурационного файла приведен ниже.

Как видно, файл конфигурации содержит ряд настроек в иерархическом виде. Каждый узел в файле настроек определяет отдельный аспект функционирования веб-приложения – настройки кеширования, настройки компиляции и отладки, строки соединения с СУБД , параметры безопасности и т.д. Для каждого узла определен собственный класс -обработчик этих настроек. Узел не может быть добавлен в конфигурационный файл , если с ним не ассоциирован никакой класс -обработчик. В противном случае при запуске приложения будет сгенерирована ошибка.

Система конфигурации . NET Framework предполагает использование файлов конфигурации и для хранения собственных параметров конфигурации приложения, а не только общих настроек. Для того, чтобы добавить свою секцию конфигурации в файл настроек, для начала следует определить эту секцию специальным образом. Для этого существует стандартная секция » configSections «. Определить секцию конфигурации можно следующим образом.

В приведенном примере мы определяем секцию с именем » MySection «. При этом должен быть создан класс » MyConfigSection «, который является обработчиком параметров этой секции. После в конфигурационном файле можно определить и саму конфигурационную секцию и задать нужные параметры.

Количество параметров, уровень вложенности и весь внешний вид секции конфигурации определяет класс -обработчик для этой конфигурационной секции. Этот класс является наследником базового класса » ConfigurationSection «, который содержит базовые механизмы для работы с данными конфигурационных файлов. В наиболее простой ситуации можно определить обработку свойств секции, в данном случае свойства » MyParam1 «. Для этого необходимо создать в классе-обработчике новое публичное свойство и разметить его соответствующим атрибутом » ConfigurationProperty «.

Такое определение позволит среде исполнения . NET Framework корректно интерпретировать конфигурационную секцию.

Следует отметить, что все конфигурационные секции, доступные по умолчанию в . NET Framework объявлены подобным образом (используя секцию » configSections «). Эти определения сделаны в глобальном файле » machine.config «.

Наконец, для получения доступа к существующим конфигурационным секциям используется объект WebConfigurationManager . Для этого следует воспользоваться статическим методом » OpenWebConfiguration » для получения объекта Configuration , а затем методом » GetSection » для получения доступа к конкретной секции. После этого, эту секцию можно привести к классу-обработчику этой секции и, используя публичные свойства последнего, работать с настройками конфигурации.

Таким образом, подсистема конфигурации . NET Framework является мощным механизмом, который позволяет, как переопределять стандартные настройки приложения, так и определять собственные параметры конфигурирования.

Краткие итоги

Типичная проблема при разработке любого приложения – способ хранения параметров приложения. В . NET Framework существует стандартный механизм, который позволяет решить эту проблему. Все конфигурационные файлы приложения хранятся в формате XML и имеют расширение «.config». При этом существует иерархия файлов конфигурации. На глобальном уровне существует два файла – machine.config и web .config.

Настройки, определенные в файле machine.config нельзя переопределять на уровне приложения, а настройки, определенные в файле web .config – можно. На уровне приложения файлы конфигурации также могут наследоваться. Для создания собственной секции настройки необходимо создать класс -обработчик для этой секции и объявить секцию в разделе » configSections «. Доступ к настройкам приложения осуществляется на основе объекта WebConfigurationManager .

Источник: intuit.ru

Цикл статей по основам Software Configuration Management

Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий.

А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.

Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года — интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт — в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase (см. linkedin в профиле). В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле — software configuration management.

А потом увидел статью от камрада altern, в которой он начал рассказывать про СМ. Речь у него пошла несколько в другом ключе — о конкретных инструментах и именовании конфигураций. Поэтому, списавшись с ним, чтобы не пересекаться по тематике наших статей, решил написать об основах того, что называется управлением конфигурацией программных средств.

Сейчас у меня уже написан материал примерно на 50 тысяч знаков — это приблизительно 5-7 среднего размера постов для Хабра. И процесс написания продолжается. Я собираюсь выкладывать написанное с небольшой периодичностью сюда и, по мере исчерпания вопросов и обсуждений, постить новые заметки.

Задача — дать обзор того, чем же вообще является CM, какие задачи он решает и какие техники при этом используются. Речь не будет идти о конкретных системах контроля версий или вообще инструментах — этого добра навалом в сети. Задача — показать универсальные для всех инструментов основы.

Что такое CM и зачем он нужен

Управление конфигурацией

Для начала определимся, что такое configuration, ведь это слово выведено в заголовок. Конфигурация – это совокупность версий рабочих продуктов. Ключевые слова – «версий продуктов».

В любом проекте есть рабочие продукты – это может быть маркетинговая документация, требования к конечному продукту, исходные коды, тесты, вспомогательные инструменты. Что считать рабочим продуктом, зависит от проекта (определение будет дано в следующей заметке). Далее, каждый продукт изменяется во времени (в этом ведь смысл разработки), и эти изменения надо как-то учитывать – кто, когда, что именно внёс и зачем он это сделал. Иными словами, учитывать, как появлялись версии продуктов.

Версия – это состояние рабочего продукта, которое может быть восстановлено в любой момент времени независимо от истории изменения.

Соответственно, управление конфигурацией – это управление наборами рабочих продуктов и их версиями. Этот процесс и есть область действия CM.

В англоязычной литературе используется термин Software Configuration Management, сокращенно SCM. Далее для простоты изложения будет использован термин управление конфигурацией и сокращение CM (читается: «сиэм»).

Схема 1. Элементы, их версии и срезы-конфигурации.

CM является одной из базовых практик любой методологии разработки ПО. Достаточно сказать, что в модели SEI CMM/CMMI (Capability Maturity Model Integration) наличие налаженного процесса управления конфигурацией – необходимое условие для получения организацией сертификата CMM/CMMI Level 2.

Замечу, что Level 2 – это самый минимальный, начальный уровень зрелости, согласно модели CMM. Level 1 получает «автоматом» организация, завершившая успешно хотя бы один проект по разработке. Поэтому и наличие CM – это минимальное требование для сертификации. Кстати, на втором уровне необходимо иметь, в числе прочего, налаженный процесс тестирования и управления требованиями. Это говорит о том, что с точки зрения стандарта CMMI, правильный configuration management так же важен, как грамотное тестирование и управление требованиями.

Так в чем же заключается такая ценность CM?

Направления ответственности CM

Управление конфигурацией работает на всех этапах жизненного цикла проекта. Появился рабочий продукт (например, файл с исходниками) – он попадает в поле деятельности CM’а. Продукт начал изменяться (мы пишем функциональность) – значит CM должен предоставить средства для контроля над изменениями и автоматически провести сам контроль, где это требуется.

Потребовалось разбить работу на команду разработчиков, а то и на несколько – проектный CM предоставляет правила и инструменты для работы. Есть, что предложить заказчику – тогда CM определяет правила стабилизации продуктов разработки и их выпуска. Надо откатиться на произвольный релиз – опять в работе CM. Понадобились метрики по изменениям или документированные политики – ну, вы поняли, к кому обратиться.

Итак, в первую очередь, CM отвечает за идентификацию рабочих продуктов, т.е. отвечает за определение того, что же будет в дальнейшем контролироваться. В следующей заметке будет подробнее про это рассказано.

Продукты выделили, дальше команда начинает работу. По ходу работы нужно периодически стабилизировать полученные результаты, подводить некоторую черту под наработками, а также определять тот базис, на основе которого будет идти разработка. Это всё также входит в сферу деятельности CM’а.

Кроме того, CM отвечает за то, что в общем случае называется отслеживанием запросов на изменения. Большинству эта область известна как системы отслеживания ошибок. Ведь никакие изменения не должны проходить спонтанно – каждое из них нужно регистрировать и затем правильным образом назначать и отслеживать – вплоть до попадание в конечный продукт. Вот тут опять остается крайним CM.

Изменения в продукты вносим, надо их отслеживать – начинает работать контроль версий. Ничто не будет потеряно – CM на страже.

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

Ну и, как всегда, «нельзя контролировать то, что нельзя измерить» — (с) Де Марко. Метрики – о них тоже будет сказано пару слов. Где измерения – там и формализация. Другими словами, всё, что связано с CM, хорошо бы документировать. Об этом тоже вкратце будет упомянуто.

Итак, каковы задачи управления конфигурацией?

• идентификация рабочих продуктов;
• стабилизация результатов работы и определение базы для дальнейшей работы;
• отслеживание запросов на изменение;
• контроль версий;
• обеспечение параллельности разработки;
• сбор метрик и формализация применяемых методов.

Для начала — достаточно. Следующая часть будет посвящено тому, как же определяются продукты и конфигурации, которыми мы будем управлять. Также коснусь вопроса о компонентной разработке, продуктовых линейках и их связи с СМ.

Ссылки для расширения кругозора:

1. en.wikipedia.org/wiki/Software_configuration_management Software Configuration Management на Википедии.
2. www2.computer.org/portal/web/swebok Software Engineering Book of Knowledge.
3. www.sei.cmu.edu/cmmi SEI CMMI Website.
4. www.cmcrossroads.com CM Crossroads the Configuration Management Community.

UPD: по просьбам трудящихся, ссылка на вторую часть: habrahabr.ru/blogs/pm/67839

Источник: habr.com

Конфигурации 1С

Помощь эксперта в выборе программы. Доставка, установка, ИТС, линия консультаций бесплатно + бонусные часы в подарок!

от 1 650 руб.

1С:Бухгалтерия 8.3

Автоматизация бухгалтерского и налогового учета, включая подготовку обязательной отчетности

от 1 650 руб.

1С:Зарплата и управление персоналом

Профессиональный инструмент для отдела кадров, расчетного отдела и HR-службы.

от 3 700 руб.

Внедрение 1С

Быстрое внедрение, внедрение по Agile, проектное внедрение. ISO 9001:2015. Оценка стоимости — бесплатно!

от 29 900 руб.

Многим хорошо известно, что существует множество разновидностей программ 1С. Среднестатистический пользователь, скорее всего, назовет три из них:

• 1С:Бухгалтерия
• 1С:Зарплата и управление персоналом
• 1С:Управление торговлей

На самом деле, компанией «1С» разработано более тысячи различных пользовательских приложений, при этом внедряется 1С:Предприятие фактически на каждом российском предприятии. Все эти программы называются конфигурациями или прикладными решениями 1С. Эта статья поможет разобраться, как выбрать конфигурацию 1С, максимально подходящую для удовлетворения потребностей вашей фирмы.

Конфигурации 1С (прикладные решения 1С) – это программы, предназначенные для автоматизации деятельности различных организаций и частных лиц.

Конфигурация в 1С запускается только в том случае, если на компьютере установлена технологическая платформа 1С:Предприятие.

Технологическая платформа 1С:Предприятие – это специальная среда или оболочка, в которой запускаются и функционируют прикладные решения 1С.

При покупке 1С пользователь приобретает комплект программ, состоящий из платформы 1С:Предприятие и одной или нескольких конфигураций 1С. Такой «комплект» (конфигурирование платформы и рабочих баз с программными инструментами управления) принято называть программным продуктом 1С.

В программный продукт также включено консультационное и технологическое сопровождение. Например, предоставляется доступ к справочной системе Информационно-технологическое сопровождение (1С:ИТС).

Примеры программных продуктов на базе платформы версии 8.3:

• Программный продукт = платформа 1С:Предприятие 8.3+1С:Бухгалетрия 8.3+1С:Зарплата и управление персоналом 8.3 (для ведения бухгалтерского, налогового учета производственного предприятия и начисления зарплаты сотрудникам в отдельной программе).
• Программный продукт = платформа 1С:Предприятие 8.3+1С:Бухгалетрия 8.3+1С:Управление торговлей 8.3+1С:Зарплата и управление персоналом 8.3 (для ведения бухгалтерского, налогового, складского учета торговой организации и начисления зарплаты сотрудникам в отдельной программе).

Все конфигурации 1С имеют похожий интерфейс, одинаковые объекты конфигурации (справочники, документы, регистры сведений и т.д.) и общие принципы работы. Таким образом, пользователь, освоивший основные действия в одной из конфигураций 1С, может с легкостью работать в других.

Некоторые из однотипных операций, доступных во всех прикладных решениях 1С:

• Заполнение справочников. Создание элементов и групп в справочниках;
• Удаление, копирование, перемещение, редактирование элементов и групп справочников;
• Ввод входящих остатков;
• Ввод документов в программе, в т.ч. создание документов путем копирования и ввод на основании;
• Работа в журналах документов;
• Формирование отчетов по итогам работы.

Технологическая платформа 1С:Предприятие разработана компанией «1С». Она постоянно развивается, учитывая потребности пользователей, обновления законодательства, а также новшества рынка. В результате, на свет постоянно появляются новые версии (например, 7.7, 8.2, 8.3) и релизы (текущие обновления) платформы 1С.

Кроме того, платформа содержит встроенный язык программирования, позволяющий внести изменения в готовую конфигурацию на основании пожеланий заказчика. Иногда, если это необходимо, на базе технологической платформы пишутся «с нуля» совершенно новые конфигурации для 1С.

Прикладные программы 1С создаются как самой фирмой «1С», так и другими разработчиками, фирмами-партнерами. Конфигурации 1С, выпущенные непосредственно компанией «1С» называются типовыми.

Таким образом, в зависимости от разработчика, конфигурации 1С бывают двух видов: типовые и нетиповые (также называются отраслевыми и специализированными решениями).

Большинство пользователей в составе программного продукта приобретают типовые решения 1С.

Достоинства

• Типовые решения 1С являются универсальными, т.е. подходят для ведения учета в различных сферах деятельности. Например, в 1С:Бухгалтерии могут работать бухгалтеры производственных предприятий, сферы услуг, торговых организаций. Конфигурация позволяет также вести учет в различных налоговых режимах (ОСН, УСН, ЕНВД).
• Типовые конфигурации 1С постоянно совершенствуются компанией «1С», которая ведет мониторинг пожеланий покупателей и учитывает опыт широкого круга пользователей. Такие прикладные решения тщательно «отлажены», более надежны в использовании и обслуживании.

Недостатки

• Потребитель использует лишь нужную ему часть возможностей типового решения, покупая при этом весь функционал программы.
• Типовая конфигурация 1С нуждается в тщательной настройке под конкретную организацию, а иногда и в «доработке» силами программистов.

Для российских предприятий фирма «1С» предлагает следующие типовые конфигурации

Максимально полно функциональные возможности системы программ 1С:Предприятие реализованы в программе 1С:ERP Управление предприятием 8.3.

Некоторые типовые конфигурации выпускаются в нескольких версиях с различным набором функциональных возможностей. Например, 1С:Бухгалтерия 8 выпускается в трех версиях: базовая, КОРП и ПРОФ.

Далее перечислены версии 1С:Бухгалтерии в порядке возрастания их функционала.

Источник: wiseadvice-it.ru

Конфигурация приложения

Это содержимое является отрывком из электронной книги для Blazor разработчиков ASP NET веб-формы для Azure, доступных в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Основным способом загрузки конфигурации приложения в веб-формы является запись в файле web.config либо на сервере, либо связанный файл конфигурации, на который ссылается web.config. Статический ConfigurationManager объект можно использовать для взаимодействия с параметрами приложения, строками подключения репозитория данных и другими расширенными поставщиками конфигурации, добавленными в приложение. Обычно для просмотра взаимодействия с конфигурацией приложения отображается следующий код:

var configurationValue = ConfigurationManager.AppSettings[«ConfigurationSettingName»]; var connectionString = ConfigurationManager.ConnectionStrings[«MyDatabaseConnectionName»].ConnectionString;

При использовании ASP.NET Core и Blazor на стороне сервера файл web.config может присутствовать, если приложение размещено на сервере Windows IIS. Однако взаимодействия ConfigurationManager с этой конфигурацией не требуется, и вы можете получить более структурированную конфигурацию приложения из других источников. Давайте посмотрим, как собирается конфигурация и как можно получить доступ к сведениям о конфигурации из файла web.config.

Источники конфигураций

ASP.NET Core признает наличие множества источников конфигурации, которые вы можете использовать для приложения. Платформа пытается предложить наиболее подходящие из этих функций по умолчанию. Конфигурация считывается и объединяется из этих различных источников с помощью ASP.NET Core. Более поздние загруженные значения для одного и того же ключа конфигурации имеют приоритет над более ранними значениями.

ASP.NET Core была разработана для обеспечения работы в облаке и упрощения настройки приложений для их пользователей и разработчиков. ASP.NET Core работает с учетом среды и знает, работает ли она в среде Production или Development . Индикатор среды задается в системной переменной среды ASPNETCORE_ENVIRONMENT . Если значение не задано, приложение по умолчанию работает в среде Production .

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

1. файла appsettings.jsв, если он есть;
2. файла appsettings..json, если он есть;
3. файла секретов пользователя на диске, если он есть;
4. Переменные среды
5. аргументов командной строки;

Формат файла appsettings.jsк и доступ к нему

Файл appsettings.jsв может быть иерархическим со значениями, структурированными как в следующем JSON:

< «section0»: < «key0»: «value», «key1»: «value» >, «section1»: < «key0»: «value», «key1»: «value» >>

При отображении с помощью вышеуказанного JSON система конфигурации преобразует дочерние значения в плоские структуры и ссылается на полные иерархические пути. Символ двоеточия ( : ) разделяет каждое свойство в иерархии. Например, ключ конфигурации section1:key0 обращается к значению key0 объектного литерала section1 .

Секреты пользователя.

• Являются значениями конфигурации, хранящимися в JSON-файле на рабочей станции разработчика, за пределами папки разработки приложения.
• Загружаются только при выполнении в среде Development .
• Связаны с конкретным приложением.
• Управляется с помощью команды user-secrets интерфейса командной строки .NET.

Настройте приложение для хранения секретов, выполнив команду user-secrets :

dotnet user-secrets init

Предыдущая команда добавляет элемент UserSecretsId в файл проекта. Элемент содержит идентификатор GUID, который используется для связывания секретов с приложением. Затем можно определить секрет с помощью команды set . Пример:

dotnet user-secrets set «Parent:ApiKey» «12345»

Предыдущая команда делает ключ конфигурации Parent:ApiKey доступным на рабочей станции разработчика со значением 12345 .

Дополнительные сведения о создании, хранении и управлении секретами пользователей см. в документе Безопасное хранения разрабатываемых секретов приложений в ASP.NET Core.

Переменные среды

Следующий набор значений, загружаемых в конфигурацию приложения, — это переменные среды системы. Все параметры переменных среды системы теперь доступны через API настройки. При чтении внутри приложения иерархические значения преобразуются в плоские структуры и разделяются символами двоеточия. Однако некоторые операционные системы не разрешают имена переменных среды с двоеточием. ASP.NET Core устраняет это ограничение, преобразуя значения с двойным подчеркиванием ( __ ) в двоеточия при обращении к ним. Значение Parent:ApiKey из раздела о секретах пользователя выше можно переопределить с помощью переменной среды Parent__ApiKey .

аргументов командной строки;

Кроме того, конфигурацию можно указать в виде аргументов командной строки при запуске приложения. Используйте двойное тире ( — ) или прямую косую черту ( / ), чтобы указать имя устанавливаемого значения конфигурации и значение, которое необходимо настроить. Синтаксис напоминает следующие команды:

dotnet run CommandLineKey1=value1 —CommandLineKey2=value2 /CommandLineKey3=value3 dotnet run —CommandLineKey1 value1 /CommandLineKey2 value2 dotnet run Parent_ApiKey=67890

Возвращение web.config

Если вы развернули приложение в Windows на IIS, файл web.config по-прежнему настраивает IIS для управления приложением. По умолчанию службы IIS добавляют ссылку на модуль ASP.NET Core (ANCM). ANCM — это собственный модуль IIS, в котором размещается приложение вместо веб-сервера Kestrel. Этот раздел web.config напоминает следующую XML-разметку:

Конфигурация конкретного приложения может быть определена путем вложения элемента environmentVariables в элемент aspNetCore . Значения, определенные в этом разделе, представлены в приложении ASP.NET Core как переменные среды. Переменные среды загружаются соответствующим образом во время выполнения этого сегмента запуска приложения.

Чтение конфигурации в приложении

Приведенная выше инструкция делает объект IConfiguration доступным в качестве переменной Configuration для всего остального шаблона Razor.

Отдельные параметры конфигурации можно прочитать, указав иерархию параметров конфигурации, которую нужно использовать в качестве параметра индексатора:

var mySetting = Configuration[«section1:key0»];

Вы можете извлечь все разделы конфигурации с помощью метода GetSection для извлечения коллекции ключей в определенном месте с синтаксисом, аналогичным GetSection(«section1») , чтобы получить конфигурацию для section1 из предыдущего примера.

Строго типизированная конфигурация

С помощью Web Forms можно было создать строго типизированный тип конфигурации, наследуемый от типа ConfigurationSection и связанных с ним типов. ConfigurationSection позволяет настроить некоторые бизнес-правила и обработку для этих значений конфигурации.

В ASP.NET Core можно указать иерархию классов, которая будет принимать значения конфигурации. Это классы:

• Наследовать от родительского класса не нужно.
• Должны быть включены свойства public , соответствующие свойствам и ссылкам на типы для структуры конфигурации, которую вы хотите зафиксировать.

Для предыдущего образца appsettings.js можно было определить следующие классы для записи значений:

public class MyConfig < public MyConfigSection section0 < get; set;>public MyConfigSection section1 < get; set;>> public class MyConfigSection < public string key0 < get; set; >public string key1 < get; set; >>

Эту иерархию классов можно заполнить, добавив следующую строку в метод Startup.ConfigureServices (или соответствующее расположение в Program.cs, используя свойство builder.Services вместо services ):

services.Configure(Configuration);

Дополнительные сведения о функции параметров можно найти в документе Шаблон параметров в ASP.NET Core.

Источник: learn.microsoft.com