Конфигурировать программу что это

5.7. Управление конфигурацией программного обеспечения

Управление конфигурацией ПО — это один из вспомогательных процессов, поддерживающих основные процессы ЖЦ ПО, прежде всего процессы разработки и сопровождения ПО.

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

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

Управление конфигурацией позволяет организовать, системати­чески учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ.

Настройка Finder

При групповой разработке сложных ПО, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, необходимо:

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

— контролировать запросы на доработку модуля, сообщения о найденной ошибке или неисправности оборудования, запросы на модификацию оборудования или ПО, задания на установку рабочего места, задания разработчику, аналитику и т.п., так как эти объекты влияют на состояние текущих версий других объектов и относятся к сфере управления изменениями;

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

— вести полный и достоверный архив всех версий всех объектов системы;

— контролировать состояние и развитие коллективно используемых ком­понентов ПО и их версий, учитывая связи компонентов системы для согласования между собой измененных частей; обеспечивать адекватность реально изменяю­щихся компонентов и их комплектной документации;

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

— изготавливать эталон­ные копии ПО и документации, хранить и поставлять их пользо­вателям в соответствии с порядком, принятым в организации. Это упрощает выпуск и поставку ПО;

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

Не показывают каналы Первый HD и Россия HD. Настройка каналов.

Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2.

Рассмотрим, как пример, управление исходным кодом.

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

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

Прикладные программисты должны придерживаться установленных правил групповой разработки.

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

Формат комментария к правке может быть таким:

10.01.2004 Ivanov: authorization bug fixed (found by Petrov)

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

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

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

Функции, структуры, наиболее важные переменные должны сопровождаться комментариями. Необходимо избегать непонятных названий вида K1, Function10.

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

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

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

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

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

Рынок систем конфигурационного управления

Без хорошего инструментария невозможно оперативно управлять конфигура­циями ПО.

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

Можно выделить четыре группы таких продуктов:

1) обеспечивающие контроль версий (Rational ClearCase, Merant PVCS, Microsoft Visual SourceSafe);

2) обеспечивающие контроль версий и изменений (Rational ClearCase/ClearQuest, PVCS Professional);

3) обеспечивающие параллельную разработку, контроль версий, изменений и рабочих процессов (PVCS Dimensions, CCC:Harvest фирмы Computer Associates);

4) обеспечивающие все вышеуказанные возможности при взаимодействии нес­кольких географически удаленных команд (Rational MultiSite, PVCS Replicator).

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

В числе недостатков ClearCase — необходимость серьезного администриро­вания, т.е. нагрузка при работе с продуктом перекладывается с конечных пользователей на администратора.

Продукт PVCS, встроен во многие системы разработки, предлагает более простой версионный контроль. Он хуже автоматизирует работу пользователей и сложнее в применении, но зато не требует отдельного сотрудника-администратора для поддержки небольших групп разработчиков. Существуют проблемы переходов от одного продукта PVCS к другому. Имеет меньшую стоимость. Может оказаться хорошим решением, если разработка идет под разными платформами (аппаратная платформа и ОС).

Продукт Microsoft Visual Source Safe осуществляет простой контроль исходных текстов и подходит для индивидуальной работы или для проектов, объединяющих нескольких человек. В нем нельзя организовать связь между участниками проекта, но он значительно дешевле и проще. Используется для ОС Windows 98, NT, 2000.

В ноябре 2002 г. компания Merant выпустила новую версию популярного инструмента для управления конфигурациями ПО PVCS Professional 7.5.

В состав пакета входят:

— PVCS Version Manager 7.5 — система контроля версий;

— PVCS Tracker Manager 7.5 — утилита формирования журнала изменений и задач;

— Configuration Builder 7.5 — утилита обеспечения стандартизованной и надежной компоновки готовых приложений.

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

Конфигурирование приложений

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

Вы конфигурируете приложения J2EE путем изменения XML-файлов в META-INF и WEB-INF каталоги в архивах приложения. Выполнение этой задачи вручную утомительно и подвержено ошибкам. Инструмент развертывания JBoss позволяет Вам конфигурировать приложения, не имея необходимость разархивировать файлы EAR, файлы WAR или файлы JAR, поскольку инструмент позволяет Вам сконфигурировать эти файлы непосредственно.

Эта глава объясняет, как запустить сервер приложений и сконфигурировать и развернуть Ваше приложение.

Запуск сервера приложений

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

1. Администратор Сервера запуска, расположенный в /Applications/Server .
2. В списке Компьютеров и Служб выберите Application Server.
3. В области конфигурации нажмите Settings. От всплывающего меню Имени Конфигурации выберите надлежащую конфигурацию.
4. Нажмите кнопку на панели инструментов Start Service. После нескольких секунд должен работать сервер приложений. Можно подтвердить, что JBoss работает путем доступа http://localhost:8080 в Вашем веб-браузере. Необходимо видеть, что названная веб-страница Добро пожаловать в JBoss/Tomcat.

Можно также запустить JBoss в Терминале со следующей командой:

$ /Library/JBoss/3.2/bin/run.sh -c deploy-standalone

Для получения подробной информации о действиях JBoss используйте develop конфигурация . Это полезно, когда необходимо удостовериться уведомления JBoss, когда Вы развертываете или не развертываете модуль, или когда необходимо определить, выдаются ли исключения, поскольку JBoss запускает развертываемое приложение. develop конфигурация производит подробный журнал действий JBoss. Более полезно при запуске сервера приложений из командной строки, потому что Вы видите результаты действий сразу в Окне терминала, из которого Вы запускаете сервер приложений.

Конфигурирование Вашего приложения

Следующие разделы учат Вас, как запустить инструмент развертывания и сконфигурировать Ваше приложение.

Запуск инструмента развертывания JBoss

Для запуска инструмента развертывания дважды щелкнуть DeploymentTool.woa в /Library/JBoss/Applications или введите следующую команду в Терминал:

$ /Library/JBoss/Applications/DeploymentTool.woa/DeploymentTool

С момента появляется Окно приложения Загрузки.

Примечание: Выполнение Инструмента Развертывания JBoss требует веб-браузера, поддерживающего Frames и Javascript. Некоторые веб-браузеры, возможно, должны иметь раскрывающееся отключенное блокирование.

Загрузка Вашего приложения

Окно приложения Загрузки — то, где Вы указываете расположение приложения или компонента, Вы хотите сконфигурировать. Несмотря на то, что окно названо Приложение Загрузки, можно также использовать инструмент развертывания для конфигурирования файлов EAR, файлов WAR и файлов JAR.

Рисунок 2-1 показывает Окно приложения Загрузки.

Введите полный путь в файл в текстовом поле в Окне приложения Загрузки и нажмите Load Application.

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

Обычно, Вы не можете сохранить приложение с недопустимыми XML-файлами. Т.е. необходимо сконфигурировать все элементы, обнаруживающиеся в красном в главном окне. Можно переопределить, это отменой выбора Проверяет XML-файлы в Окне приложения Загрузки. Однако Вы не можете быть в состоянии перезагрузить приложение, сохраненное в этом состоянии. После того, как инструмент развертывания загружает приложение, он выводит на экран Загруженное Окно приложения, показанное на рисунке 2-2 .

Нажмите «Click here to continue» для хождения дальше. Инструмент развертывания выводит на экран главное окно (также известный как окно навигации). Главное окно представляет иерархию компонентов, сгенерированных от настоящего XML-файлов в META-INF и WEB-INF каталоги компонентов содержали в архиве, который Вы открыли. Например, рисунок 2-3 показывает компонентное настоящее в petstore.ear файл приложения Зоомагазина Микросистемы Sun . Необходимо сконфигурировать элементы красного цвета для сохранения приложения. Конфигурирование Компонентов Вашего Приложения показывает Вам, как сделать это.

Рисунок 2-3 показывает компоненты petstore.ear архив . Следующий список описывает некоторые элементы в главном окне:

• PetStoreEAR (Приложение) Представляет архив корпоративного приложения Зоомагазина.
• Параметры настройки приложения , Нажимающие на эту ссылку, позволяют Вам конфигурировать настройки, влияющие на все модули в архиве, когда развертывается приложение.
• AsyncSenderEJB (EJB) Представляет архив (файл JAR), который содержит файлы, определяющие компонент уровня предприятия AsyncSender ( asyncsender-ejb.jar файл). Щелчок на ссылку Module Settings позволяет Вам сконфигурировать настройки всего модуля и установить значения по умолчанию для некоторых настроек для всех компонентов уровня предприятия, определенных в модуле. Посмотрите Конфигурируют Модуль Клиента для примера.
• PetStoreWAR (Веб-приложение) Представляет архив (файл WAR), который содержит файлы, определяющие веб-модуль корпоративного приложения Зоомагазина.

Конфигурирование компонентов приложения

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

Окно конфигурации также содержит область Quick Config , содержащую элементы компонента, который необходимо сконфигурировать для приложения, чтобы быть развертываемыми. Рисунок 2-4 показывает область Quick Config модуля CatalogEJB . Это указывает, что должны быть сконфигурированы ссылки ресурса JBoss. Ссылки ресурса JBoss также появляются в области JNDI Resource Refs. Однако необходимо сконфигурировать их в только одной из двух областей.

Примечание: Для приложений со многими компонентами можно хотеть сконфигурировать страницы Quick Config недопустимых компонентов и сохранить приложение. Тогда можно сконфигурировать каждый компонент далее постепенным способом.

Некоторые настройки применяются ко всему модулю, например, ролям безопасности. Кроме того, некоторые настройки модуля служат значениями по умолчанию для настроек отдельных компонентов в модуле. Рисунок 2-5 показывает некоторые настройки модуля модуля CustomerJAR petstore.ear приложение. Конфигурирование настроек модулей может помочь ускорить конфигурацию модуля. Посмотрите Конфигурируют Настройки Всего модуля для примера.

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

Сохранение сконфигурированного приложения

Для сохранения сконфигурированного приложения, т.е. когда никакие компоненты не показаны в красном в главном окне, нажимают Save в вершине главного окна. Окно приложения Сохранения (рисунок 2-6) появляется.

Введите место назначения сконфигурированного приложения в текстовом поле Окна приложения Сохранения и нажмите Save Application.

Развертывание Вашего приложения

Для развертывания сконфигурированного приложения от инструмента развертывания просто сохраните приложение к /Library/JBoss/3.2/deploy в единственном развертывании серверов или /Library/JBoss/3.2/farm в кластерном развертывании .

Источник: spec-zone.ru

Конфигурировать программу что это

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

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

Программы работают на машинах. Они почти всегда записаны в исходных текстах и строятся из них. Компиляция — это процесс, которым часто, но не всегда создаются программы.

Здесь слово «основная» относится к среде, в которой будут откомпилированы эти исходные тексты. Имя основной среды не имеет отношения к имени Вашей главной машины, например, ucbvax, prep.ai.mit.edu или att.com. Вместо них оно относится к sun4 или dec3100.

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

Например, если нам требуется конфигурация нашего воображаемого калькулятора для компилирования на SparcStation, мы должны конфигурировать для среды sun4. Т.е. с нашей системой конфигурации:

cd desk-calculator ; ./configure sun4

«configure» — это программы на языке оболочки Unix, которые устанавливают Makefiles (файлы для утилиты «make»), подкаталоги и символические ссылки для компилирования на sun4.

Основная среда не обязательно привязана к той машине, на которой были откомпилированы утилиты; можно имитировать основную среду sun3 на sun4. Если мы хотим использовать кросс-компилятор на sun4 для компилирования программ, предназначенных для работы на sun3, мы сконфигурируем исходный текст для sun3:

cd desk-calculator ; ./configure sun3

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

Основная среда не имеет отношения к машине, на которой будет работать созданная программа. На sun4 можно обеспечить эмуляцию среды sun3, и программы, скомпилированные на sun3, будут работать на sun4. Эта практика часто используется в индивидуальных программах для компенсации отличий различных архитектур и операционных систем. Например, некоторые операционные системы не обеспечивают функцию bcopy, и она эмулируется, используя функцию memcpy.

Основная среда — это просто среда, в которой будет скомпилирована эта программа.

Многие программы имеют опции времени компиляции. Это возможности программы, которые могут быть встроены в программу и зависят от выбора человека, проводящего компиляцию. Мы определяем это как опции конфигурации. Например, наш калькулятор возможно скомпилировать в программу, которая использует инфиксную или постфиксную запись как параметры конфигурации. Чтобы выбрать инфиксную запись при работе на sun3:

./configure sun3 —enable-notaion=infix
а постфиксную для sun4:
./configure sun4 —enable-notaion=postfix

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

mkdir ../objdir.sun4 (cd ../objdir.sun4 ; ../configure sun4 —enable-notation=postfix —srcdir=../ scr) mkdir ../objdir.sun3 (cd ../objdir.sun3 ; ../configure sun3 —enable-notation=infix —srcdir=../ scr)

создадут подкаталоги для промежуточных частей конфигураций для sun4 и sun3. Это необходимо, так как предыдущие системы были способны только на одну конфигурацию одновременно, иначе вторая конфигурация будет записана поверх первой. Нам нужно сохранить описанные изменения, которые мы получили во время конфигурации; порядок аргументов не важен, но должен присутствовать аргумент без ‘-‘, который будет именем основной среды.

Основываясь на этих примерах, будем предполагать, что нам необходимо построить утилиты на каком-то месте, и не использовать параметр —srcdir, но будем помнить о нем.

Для инсталяции программы конфигурирующей системе необходимо знать, где Вы хотите ее установить. По умолчанию она будет храниться в ‘/usr/local’. Мы ссылаемся на это расположение с помощью ‘$(prefix)’. Все запускаемые пользовательские программы будут установлены в ‘$(prefix)/bin’. Все другие программы и файлы будут установлены в подкаталоге ‘$(prefix)/lib’.

Вы можете сменить ‘$(prefix)’ только как параметр конфигурации:

./configure sun4 —enable-notation=postfix —prefix=/local
Сконфигурируйте исходный текст следующим образом:
make install

Это распределит программу в каталогах ‘/local/bin’ и ‘/local/lib/gcc’. Если Вы смените ‘$(prefix)’ после компилирования исходного текста, Вам необходимо набрать:

make clean

перед тем как будут произведены изменения, так как некоторым утилитам необходимо знать положение других утилит.

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

Источник: www.opennet.ru

Что такое конфигурации и для чего они нужны в телефоне

18:59 26-12-2020 DimonVideo

В смартфоне, ноутбуке или компьютере есть огромное количество разных сложных комплектующих и технических характеристик. Мало кто задумывается об их существовании в процессе пользования гаджетами. Тем более, практически никто не знает о том, что такое конфигурация, или слышал о таком понятии только вскользь. Компания Configshop, сайт: https://configshop.net/en профессионально занимается конфигами для разных целей.

Что такое конфигурации и для чего они нужны в телефоне

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

На нашем сайте вы можете приобрести:

• — Конфигурации Windows;
• — Мобильные конфигурации;
• — Конфигурации MacOS.

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

При помощи конфиг, хозяин смартфона может задать ряд параметров своему устройству. Хранится они могут в текстовых файлах. Вы можете менять их по своему усмотрению. Существуют конфиги, которые создаются при производстве изделий. Чтобы изменить программу, ее необходимо собрать снова.

Очень часто для хранения конфиг используют отдельную БД.

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

Чтобы ваш телефон работал корректно, не пропускайте предлагаемые обновления. Это позволит вам не только корректно эксплуатировать аппарат, но и откроет новые возможности и функции. Таким образом вы повысите продуктивность работы смартфона и устраните возможные ошибки.

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

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

Настройка приложений с использованием файлов конфигурации

платформа .NET Framework позволяет разработчикам и администраторам контролировать и гибко управлять тем, как приложения выполняются с помощью файлов конфигурации. Файлы конфигурации имеют формат XML, и при необходимости их можно изменять. Администратор может контролировать, к каким из защищенных ресурсов может осуществлять доступ приложение, какие оно будет использовать версии сборок и где расположены удаленные объекты и приложения. Разработчики могут задавать параметры в файлах конфигурации, устраняя необходимость в перекомпиляции приложения при каждом изменении той или иной установки. В этом разделе рассказывается, какие параметры могут быть настроены и для чего может потребоваться настройка приложения.

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

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

Формат файлов конфигурации

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

Как и во всех XML-файлах, в файлах конфигурации учитывается регистр.

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

Файлы конфигурации компьютера

Файл конфигурации компьютера Machine.configсодержит параметры, которые применяются ко всему компьютеру. Этот файл находится в каталоге %путь установки среды выполнения%Config. Machine.config содержит параметры конфигурации для привязки сборки на уровне компьютера, встроенных каналов удаленного взаимодействия и ASP.NET.

При развертывании приложения с помощью команды XCOPY файл конфигурации компьютера не копируется.

Дополнительные сведения об использовании файла конфигурации компьютера средой CLR для привязки сборок см. в разделе Обнаружение сборок в среде выполнения.

Файлы конфигурации приложения

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

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

• Приложение, размещенное в исполняемом файле. Эти приложения имеют два файла конфигурации: исходный файл конфигурации, который изменяется разработчиком во время разработки, и выходной файл, распространяемый вместе с приложением. При разработке в Visual Studio разместите исходный файл конфигурации приложения в каталоге проекта и установите для его свойства Копировать в выходной каталог значение Всегда копировать или Копировать, если новее. По умолчанию имя файла конфигурации — App.config. Чтобы создать выходной файл конфигурации, развернутый с помощью приложения, Visual Studio копирует исходный файл конфигурации в каталог, в который размещается скомпилированная сборка. Этот файл называется .exe.config. Например, приложение с именем myApp.exe будет иметь выходной файл конфигурации с именемmyApp.exe.config. В некоторых случаях Visual Studio может изменить выходной файл конфигурации; дополнительные сведения см. в разделе Перенаправление версий сборки на уровне приложения статьи Перенаправление версий сборки.
• Приложение, размещенное в ASP.NET. Дополнительные сведения о файлах конфигурации ASP.NET см. в Параметры ASP.NET конфигурации.
• Приложение, размещенное в Internet Explorer. Если приложение, размещенное в Internet Explorer, имеет файл конфигурации, расположение этого файла указывается в теге со следующим синтаксисом : В этом теге location — это URL-адрес файла конфигурации. Таким образом задается базовая папка приложения. Файл конфигурации должен находиться на том же веб-сайте, что и приложение.

Файлы конфигурации безопасности

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

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

Ниже приведено расположение файлов конфигурации безопасности.

• Файл конфигурации политики предприятия: %путь-установки-среды-выполнения%ConfigEnterprisesec.config
• Файл конфигурации политики компьютера: %путь-установки-среды-выполнения%ConfigSecurity.config
• Файл конфигурации политики пользователя: %USERPROFILE%Application dataMicrosoftCLR security configvxx.xxSecurity.config

См. также

• Схема файла конфигурации
• Указание расположения сборки
• Перенаправление версий сборки
• Администрирование веб-сайта ASP.NET
• Управление политиками безопасности
• Caspol.exe (средство настройки политики управления доступом для кода)
• Сборки в .NET

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