Что это config xml
Настройка приложений с использованием файлов конфигурации
С помощью классов из пространства имен System.Configuration управляемый код может считывать установки из конфигурационных файлов, но не записывать их в эти файлы.
В этом разделе описан синтаксис файлов конфигурации и приведены сведения о трех типах таких файлов: конфигурации компьютера, приложения и безопасности.
Формат файлов конфигурации
Как и во всех XML-файлах, в файлах конфигурации учитывается регистр.
Файлы конфигурации компьютеров
В файле конфигурации компьютера, Machine.config, задаются параметры, влияющие на работу компьютера в целом. Этот файл находится в каталоге %путь установки среды выполнения%\Config. В файле Machine.config задаются параметры конфигурации для привязки сборок компьютера, встроенных каналов удаленного взаимодействия и ASP.NET.
При развертывании приложения с помощью команды XCOPY файл конфигурации компьютера не копируется.
Дополнительные сведения об использовании файла конфигурации компьютера средой CLR для привязки сборок см. в разделе Обнаружение сборок в среде выполнения.
Файлы конфигурации приложений
В файле конфигурации приложения находятся параметры приложения. В этом файле содержатся параметры конфигурации, считываемые средой CLR (например, политика привязки сборок, удаленные объекты и т. д.) и приложением.
Имя и расположение файла конфигурации приложения зависят от места размещения приложения, которым может быть одно из указанных ниже.
Приложение, размещенное в исполняемом файле.
Такие приложения имеют два файла конфигурации: исходный файл конфигурации, который изменяется разработчиком во время разработки, и выходной файл, распространяемый с приложением.
При разработке в Visual Studio разместите исходный файл конфигурации приложения в каталоге проекта и установите для его свойства Копировать в выходной каталог значение Всегда копировать или Копировать, если новее. Имя файла конфигурации — это имя приложения с расширением CONFIG. Например, исходный файл конфигурации приложения myApp.exe должен называться myApp.exe.config.
Visual Studio автоматически копирует исходный файл конфигурации в каталог, где находится скомпилированная сборка, чтобы создать выходной файл конфигурации, развертываемый вместе с приложением. В некоторых случаях Visual Studio может изменить выходной файл конфигурации; дополнительные сведения см. в разделе Перенаправление версий сборки на уровне приложения статьи Перенаправление версий сборки.
Приложение, размещенное в ASP.NET.
дополнительные сведения о ASP.NET файлах конфигурации см. в разделе ASP.NET configuration Параметры.
Приложение, размещенное в Internet Explorer.
В этом теге location — это URL-адрес файла конфигурации. Таким образом задается базовая папка приложения. Файл конфигурации должен находиться на том же веб-сайте, что и приложение.
Файлы конфигурации безопасности
В файлах конфигурации безопасности содержатся сведения об иерархии групп кода и наборах разрешений, связанных с уровнем политики. Для изменения политики безопасности настоятельно рекомендуется использовать средство политики безопасности доступа кода (Caspol.exe), что гарантирует целостность файлов конфигурации безопасности.
Ниже приведено расположение файлов конфигурации безопасности.
Файл конфигурации политики предприятия: %путь-установки-среды-выполнения%\Config\Enterprisesec.config
Файл конфигурации политики компьютера: %путь-установки-среды-выполнения%\Config\Security.config
Файл конфигурации политики пользователя: %USERPROFILE%\Application data\Microsoft\CLR security config\v xx.xx\Security.config
в этом разделе
Практическое руководство. Поиск сборок с помощью DEVPATH
Описание процесса настройки среды выполнения для использования переменной среды DEVPATH при поиске сборок.
Перенаправление версий сборки
Инструкции по указанию местоположения и версии сборки, которая должна использоваться приложением.
Указание расположения сборки
Сведения о том, как указать среде выполнения, где она должна осуществлять поиск сборки.
Настройка криптографических классов
Описание процесса сопоставления имени алгоритма криптографическому классу и идентификатора объекта в криптографическому алгоритму.
как создать политику Publisher
Сведения о том, куда и каким образом нужно добавить файл политики издателя, чтобы задать перенаправление сборки и параметры базового каталога кода.
Схема файла конфигурации
Описывается иерархия схемы для запуска, среды выполнения, сети и других типов параметров конфигурации.
Config.xml
config.xml is a global configuration file that controls many aspects of a cordova application’s behavior. This platform-agnostic XML file is arranged based on the W3C’s Packaged Web Apps (Widgets) specification, and extended to specify core Cordova API features, plugins, and platform-specific settings.
For projects created with the Cordova CLI (described in The Command-Line Interface), this file can be found in the top-level directory:
When using the CLI to build a project, versions of this file are passively copied into various platforms/ subdirectories. For example:
In addition to the various configuration options detailed below, you can also configure an application’s core set of images for each target platform. See Customize icons topic for more information.
widget
Root element of the config.xml document.
Specifies the app’s formal name, as it appears on the device’s home screen and within app-store interfaces.
short name
Specifies an optional display name for the app. Sometimes the app name should be displayed differently on device’s home screen than on informational and app-store interfaces due to limited space.
description
Specifies metadata that may appear within app-store listings.
author
Specifies contact information that may appear within app-store listings.
Attributes(type) Only for platform: | Description |
---|---|
email(string) | Required Email of the author. |
href(string) | Required Website of the author. |
content
Defines the app’s starting page in the top-level web assets directory. The default value is index.html, which customarily appears in a project’s top-level www directory.
Attributes(type)
Only for platform: | Description —————— | ———— src(string) | Required
Defines the app’s starting page in the top-level web assets directory. The default value is index.html, which customarily appears in a project’s top-level www directory.
access
Defines the set of external domains the app is allowed to communicate with. The default value shown above allows it to access any server. See the Domain Whitelist Guide for details.
Attributes(type)
Only for platform: | Description —————— | ———— origin(string) | Required
Defines the set of external domains the app is allowed to communicate with. The default value shown above allows it to access any server. See the Domain Whitelist Guide for details.
allow-navigation
Controls which URLs the WebView itself can be navigated to. Applies to top-level navigations only.
Attributes(type)
Only for platform: | Description —————— | ———— href(string) | Required
Defines the set of external domains the WebView is allowed to navigate to. See the cordova-plugin-whitelist cordova-plugin-whitelist for details.
allow-intent
Controls which URLs the app is allowed to ask the system to open. By default, no external URLs are allowed.
Attributes(type)
Only for platform: | Description —————— | ———— href(string) | Required
Defines which URLs the app is allowed to ask the system to open. See the cordova-plugin-whitelist cordova-plugin-whitelist for details.
edit-config
See [ docs][edit_config] for plugin.xml.
config-file
See [ docs][config_file] for plugin.xml.
engine
Specifies details about what platform to restore during a prepare.
Attributes(type) Only for platform: | Description |
---|---|
name(string) | Required Name of the platform to be restored |
spec(string) | Required Details about the platform to be restored. This could be a major.minor.patch version number, a directory containing the platform or a url pointing to a git repository. This information will be used to retrieve the platform code to restore from NPM, a local directory or a git repository. See Platform Spec for further details. |
plugin
Attributes(type) Only for platform: | Description |
---|---|
name(string) | Required Name of the plugin to be restored |
spec(string) | Required Details about the plugin to be restored. This could be a major.minor.patch version number, a directory containing the plugin or a url pointing to a git repository. This information will be used to retrieve the plugin code to restore from NPM, a local directory or a git repository. See Plugin Spec for further details. |
variable
Attributes(type) Only for platform: | Description |
---|---|
name(string) | Required Name of the CLI variable. Can only contain capital letters, digits, and underscores. |
value(string) | Required Value of the CLI variable to be used when restoring the parent plugin during a prepare. |
preference
Sets various options as pairs of name/value attributes. Each preference’s name is case-insensitive. Many preferences are unique to specific platforms, and will be indicated as such.
feature
If you use the CLI to build applications, you use the plugin command to enable device APIs. This does not modify the top-level config.xml file, so the element does not apply to your workflow. If you work directly in an SDK and using the platform-specific config.xml file as source, you use the tag to enable device-level APIs and external plugins. They often appear with custom values in platform-specific config.xml files. See the API Reference for details on how to specify each feature. See the [Plugin Development Guide](../guide/hybrid/plugins/index.html) for more information on plugins. NOTE: Most of the time, you do NOT want to set this directly.
Attributes(type) Only for platform: | Description |
---|---|
name(string) | Required The name of the plugin to enable. |
param
Used to specify certain plugin parameters such as: what package to retrieve the plugin code from, and whether the plugin code is to be initialized during the Webview’s initialization.
Attributes(type) Only for platform: | Description |
---|---|
name(string) ==iOS== ==OS X== ==Android== | Required Allowed values: android-package, ios-package, osx-package, onload. ‘ios-package’, ‘osx-package’ and ‘android-package’ are used to specify the name of the package (as specified by the ‘value’ attribute) to be used to initialize the plugin code, while ‘onload’ is used to specify whether the corresponding plugin (as specified in the ‘value’ attribute) is to be instantiated when the controller is initialized. |
value(string or boolean) ==iOS== ==OS X== ==Android== | Required Specifies the name of the package to be used to initialize the plugin code (when the ‘name’ attribute is android-package, ios-package or osx-package), specifies the name of the plugin to be loaded during controller initialization (when ‘name’ attribute is set to ‘onload’). |
platform
When using the CLI to build applications, it is sometimes necessary to specify preferences or other elements specific to a particular platform. Use the
element to specify configuration that should only appear in a single platform-specific config.xml file.
Attributes(type) Only for platform: | Description |
---|---|
name(string) | Required The platform whose preferences are being defined. |
Represents your custom script which will be called by Cordova when certain action occurs (for example, after plugin is added or platform prepare logic is invoked). This is useful when you need to extend default Cordova functionality. See Hooks Guide for more information.
Использование Config.xml для выполнения задач установки в Skype для бизнеса клиентах
Сводка: Использование файла Config.xml для указания дополнительных инструкций по установке.
Хотя Центр развертывания Office является основным средством настраиваемой установки, администраторы могут использовать файл Config.xml, чтобы задать для установки дополнительные инструкции, недоступные в Центре развертывания Office. Следующие настройки выполнимы только с помощью файла Config.xml:
задание пути для точки сетевой установки;
выбор устанавливаемых продуктов;
настройка ведения журнала и местоположения файла настроек установки и обновлений ПО;
задание параметров установки, таких как имя пользователя;
копирование локального источника установки на компьютер пользователя без установки Office;
Добавление или удаление устанавливаемых языков.
Рекомендуется использовать файл Config.xml для настройки Skype для бизнеса установки.
По умолчанию Config.xml файл, хранимый в основной папке продукта (например, \ продукт. WW) направляет установку для установки этого продукта. Например, Config.xml в следующей папке устанавливается Skype для бизнеса:
Элементы Config.xml, наиболее часто используемые для Skype для бизнеса, перечислены в следующей таблице.
Элементы Config.xml
Элемент | Описание |
---|---|
Конфигурация | Элемент верхнего уровня (обязательный). Содержит атрибут Product, например: Product=Lync (Это будет работать для Skype для бизнеса клиентов) |
OptionState | Определяет, как при установке будут обрабатываться компоненты конкретного продукта. Используйте следующие атрибуты, чтобы предотвратить установку Business Connectivity Services, которая включает общие компоненты, которые мешают Outlook: State=»Absent» |
Отображение | Уровень пользовательского интерфейса, отображаемого пользователю программой установки. Обычно используются следующие атрибуты: CompletionNotice=»Yes» |
Ведение журнала | Параметры ведения журнала программой установки. Обычно используются следующие атрибуты: Тип =»Off» |
Параметр | Определяет значения для свойств программы установщика Windows. Обычно используются следующие атрибуты: Настройка имени (имя свойства Windows установки) Значение=» (значение для назначения свойству) |
DistributionPoint | Полный доменный путь точки сетевой установки, из которой запускается установка. Содержит атрибут Location: Путь Location=» |
В следующем примере Config.xml файл для типичной бесшумной установки Skype для бизнеса клиента.
Подробные сведения об использовании файла Config.xml для выполнения задач Office и обслуживания доступны по этому https://go.microsoft.com/fwlink/p/?linkid=267514 сайту.
Изменение файла Config.xml
Откройте файл Config.xml с помощью текстового редактора, такого как «Блокнот».
Найдите строки, содержащие элементы, которые нужно изменить.
Измените запись для элемента, используя нужные значения параметров автоматической установки. Убедитесь, что вы удалите делимитеры комментариев» «. Например, используйте следующий синтаксис:
Настройка файлов XML средства миграции пользовательской среды
В этой теме
Обзор
Чтобы изменить миграцию, сделайте одно или несколько из следующих.
Дополнительные сведения об исключении данных см. в разделе Exclude Files и Параметры.
Примечание.
В каждом из этих файлов можно использовать символ звездочки (*). Однако нельзя использовать знак вопроса (?) в качестве символа под диктовки.
Файл MigApp.xml. Укажите этот файл с помощью команд ScanState и LoadState для переноса параметров приложений.
Файл MigDocs.xml. Укажите этот файл с помощью средств ScanState и LoadState для переноса всех папок и файлов пользователей, найденных функцией помощника MigXmlHelper.GenerateDocPatterns. Эта функция-помощник находит пользовательские данные, которые находятся на корневом диске и в каталоге Пользователей. Однако он не находит и не переносит данные приложений, файлы программ или файлы в Windows каталоге. Вы можете изменить MigDocs.xml файл.
Файл MigUser.xml. Укажите этот файл как командами ScanState, так и LoadState для переноса папок, файлов и типов файлов. Вы можете изменить MigUser.xml файл. Этот файл не содержит правил, которые переносят определенные учетные записи пользователей. Единственный способ указать, какие учетные записи пользователей мигрировать, находится в командной строке с помощью параметров ScanState и LoadState.
Примечание.
Не используйте файлы MigUser.xml MigDocs.xml вместе. Дополнительные сведения см. в разделах Определение типов файлов, файлов и папок, а также разделы «Лучшие практики USMT».
Файл Config.xml
После создания этого файла необходимо указать его только с помощью команды ScanState с помощью параметра /Config для его влияния на миграцию. Однако, если вы хотите исключить дополнительные данные, перенесенные в магазин, измените файл Config.xml и укажите обновленный файл с командой LoadState. Например, если вы собрали папку Мои документы в магазине, но решите, что не хотите перенести папку Мои документы на компьютер назначения, вы можете изменить файл Config.xml, чтобы указать перед запуском команды migrate=»no» LoadState, и файл не будет перенесен. Дополнительные сведения о приоритетах, которые имеют место при исключении данных, см. в разделе Exclude Files и Параметры.
Кроме того, обратите внимание на следующие функции с Config.xml файлом:
Если у вас по ошибке есть две строки кода для одного компонента, в котором указана одна строка, а другая migrate=»no» migrate=»yes» строка, компонент будет перенесен.
В USMT существует несколько политик миграции, которые можно настроить в Config.xml файле. Например, можно настроить дополнительные параметры ** ** ** **и ** ** Дополнительные сведения см. в разделеConfig.xml File.
Примечание.
Чтобы исключить компонент из Config.xml, установите значение переноса на «нет». Удаление тега XML для компонента из файла Config.xml не исключает его из миграции.
Примеры:
Следующая команда создает файл Config.xml в текущем каталоге, но не создает магазин:
scanstate /i:migapp.xml /i:migdocs.xml /genconfig:config.xml /v:5
scanstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /o /config:config.xml /v:5 /encrypt /key:»mykey»
Следующая команда расшифровка магазина и миграция файлов и параметров:
loadstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /v:5 /decrypt /key:»mykey»
Дополнительные сведения
Дополнительные сведения об изменении перенесенных файлов и параметров см. в разделе Средство миграции состояния пользователя (USMT).
Ответы на распространенные вопросы см. в разделе «.xml файлы» в разделе Часто задамые вопросы.
Что представляют собой файлы миграции XML
Вы можете изменить поведение базового средства миграции состояния пользователя (USMT) 10.0 с помощью XML-файлов; эти файлы предоставляют инструкции о том, где и как инструменты USMT должны собирать и применять файлы и параметры. USMT включает три XML-файла, которые можно использовать для настройки базовой миграции: файлы MigDocs.xml и MigUser.xml, которые изменяют процесс обнаружения файлов на исходных компьютерах, и файл MigApps.xml, необходимый для переноса поддерживаемых параметров приложения. Вы также можете создать и изменить пользовательские XML-файлы и Config.xml файл для дальнейшей настройки миграции.
В этом разделе представлен обзор XML-файлов по умолчанию и настраиваемой миграции, а также рекомендации по созданию и редактированию настраиваемой версии MigDocs.xml файла. В MigDocs.xml используется новая функция GenerateDocPatterns, доступная в USMT, чтобы автоматически находить документы пользователей на исходных компьютерах.
В этой теме
Обзор файла Config.xml
При изменении элементов XML в файле Config.xml необходимо изменить элемент **** и установить свойство переноса на нет, а не удалять элемент из файла. Если удалить элемент вместо настройки свойства, компонент по-прежнему может быть перенесен по правилам в другие XML-файлы.
Обзор файла MigApp.xml
Файл MigApp.xml USMT содержит инструкции по переносу параметров приложений, перечисленных в списке What Does USMT Migrate?. Необходимо включить файл MigApp.xml при использовании средств ScanState и LoadState, используя этот параметр для /i переноса параметров приложения. Файлы MigDocs.xml MigUser.xml не переносят параметры приложений. Можно создать настраиваемый XML-файл, чтобы включить дополнительные приложения. Дополнительные сведения см. в материалах Customize USMT XML Files.
Файл MigApps.xml будет обнаруживать и мигрировать файлы PST, связанные с Microsoft Office Outlook. Дополнительные сведения о переносе файлов PST, не связанных с Outlook, см. в примере правил миграции для настраиваемых версий XML-файлов.
Обзор файла MigDocs.xml
В MigDocs.xml используется новая функция помощника GenerateDocPatterns для создания инструкций для USMT по переносу файлов с исходных компьютеров в зависимости от расположения файлов. Вы можете использовать файл MigDocs.xml средствами ScanState и LoadState для выполнения более целенаправленной миграции, чем использование USMT без инструкций XML.
По умолчанию MigDocs.xml мигрирует следующее:
Все файлы на корне диска, кроме %WINDIR%, %PROGRAMFILES%, %PROGRAMDATA%, или %USERS%.
Все папки в корневом каталоге всех фиксированных дисков. Например: c:\data_mail\\\]
Все файлы из корневой папки Профилей, за исключением файлов в профиле системы. Например: c:\users\name[mail.pst]
Все папки из корневой папки Профили, за исключением системных папок. Например: c:\users\name\new folder\\\\]
Стандартные общие папки:
Стандартные папки профиля пользователя для каждого пользователя:
Файл MigDocs.xml по умолчанию не будет перенесен следующим образом:
Файлы, помеченные как скрытыми, так и системными атрибутами.
Файлы и папки на съемных дисках.
Данные из папок %WINDIR%, %PROGRAMDATA% и %PROGRAMFILES%.
Папки, содержащие установленные приложения.
Вы также можете использовать параметр /genmigxml с помощью средства ScanState для проверки и изменения переноса файлов.
Обзор файла MigUser.xml
Файл MigUser.xml содержит инструкции для USMT по переносу пользовательских файлов на основе расширений имен файлов. Вы можете использовать файл MigUser.xml средствами ScanState и LoadState для выполнения более целенаправленной миграции, чем использование USMT без инструкций XML. В MigUser.xml будут собраны все файлы из стандартных папок профиля пользователя и все файлы на компьютере с указанными расширениями имен файлов.
По умолчанию MigUser.xml мигрирует следующее:
Все файлы из стандартных папок профиля пользователя, которые описываются как:
Файлы со следующими расширениями:
По умолчанию MigUser.xml не переносит следующие файлы:
Файлы, помеченные как скрытыми, так и системными атрибутами.
Файлы и папки на съемных дисках,
Данные из папок %WINDIR%, %PROGRAMFILES%, %PROGRAMDATA%.
ACLS для файлов в папках за пределами профиля пользователя.
Каждое расширение имени файла, которое вы включаете в правила MigUser.xml файла, увеличивает время, необходимое инструменту ScanState для сбора файлов для миграции. При переносе более 300 типов файлов может возникнуть медленная миграция. Дополнительные сведения о других способах организации миграции данных см. в разделе Использование нескольких XML-файлов этого документа.
Использование нескольких XML-файлов
С помощью средств ScanState и LoadState можно использовать несколько XML-файлов. Каждый XML-файлы по умолчанию, включенные в USMT или созданные с помощью USMT, настроены для определенного компонента миграции. Вы также можете использовать настраиваемые XML-файлы, чтобы дополнить эти файлы по умолчанию дополнительными правилами миграции.
XML-файл миграции | Изменяет следующие компоненты: |
---|---|
Config.xml файл | Компоненты операционной системы, такие как обои для рабочего стола и фоновая тема. Вы также можете перегрузить config.xml включить некоторые параметры приложений и документов, создавая config.xml файл с другими XML-файлами по умолчанию. Дополнительные сведения см. в материалах Customize USMT XML Files and Config.xml File. |
MigApps.xml файл | Параметры приложений. |
MigUser.xml или MigDocs.xml файлы | Пользовательские файлы и параметры профилей. |
Настраиваемые XML-файлы | Параметры приложений, параметры профилей пользователей или пользовательские файлы выходят за рамки правил, содержащихся в других XML-файлах. |
Например, вы можете использовать все типы XML-файлов миграции для одной миграции, как в следующем примере:
Правила XML для переноса файлов пользователей
Не следует использовать файлы MigUser.xml и MigDocs.xml вместе в одной команде. Использование обоих XML-файлов может привести к дублированию некоторых перенесенных файлов. Это происходит, когда в каждом XML-файле даются противоречивые инструкции по целевому расположению. Целевой файл будет храниться один раз во время миграции, но каждый XML-файл будет применяться к другому расположению на компьютере назначения.
Если набор данных неизвестен или многие файлы хранятся за пределами стандартных папок профиля пользователя, MigDocs.xml лучше, чем файл MigUser.xml, так как файл MigDocs.xml будет собирать более широкий объем данных. Файл MigDocs.xml переносит папки данных в зависимости от расположения. Файл MigUser.xml переносит только файлы с указанными расширениями имен файлов.
Если вы хотите больше контролировать миграцию, можно создать настраиваемые XML-файлы. См. раздел Создание и редактирование настраиваемого xml-файла этого документа.
Создание и редактирование пользовательского XML-файла
Вы можете использовать параметр командной строки /genmigxml, чтобы определить, какие файлы будут включены в миграцию. Параметр /genmigxml создает файл в задатке, чтобы можно было просмотреть правила XML и внести необходимые изменения.
Если переустановить USMT, XML-файлы миграции по умолчанию будут перезаписаны, а все настройки, которые вы делаете непосредственно для этих файлов, будут потеряны. Рассмотрите возможность создания отдельных XML-файлов для пользовательских правил миграции и сохранения их в безопасном расположении.
Создание файла правил миграции XML для исходных компьютеров:
Нажмите кнопку Начните, щелкните Все программы, щелкните Вспомогательноеоборудование, щелкните правой кнопкой мыши командноеподсказок, а затем нажмите кнопку Запустить как.
Выберите учетную запись с привилегиями администратора, вводить пароль и нажмите кнопку ОК.
В командной подсказке введите:
Где * * — это расположение на вашем исходных компьютерах, где сохранены файлы и инструменты USMT, * * аfilepath.xml— полный путь к файлу, в котором можно сохранить отчет. Например, введите:
Функция GenerateDocPatterns
Файл MigDocs.xml вызывает функцию GenerateDocPatterns, которая принимает три значения Boolean. Вы можете изменить параметры, чтобы изменить способ создания MigDocs.xml XML-правил для миграции.
Значение по умолчанию: False
C:\Program Files\Microsoft Office[.doc]
Если детская папка включенной папки содержит установленное приложение, ScanProgramFiles также создаст правило исключения для детской папки. Все папки в папке приложения будут повторно отсканированы для зарегистрированных расширений имен файлов.
Значение по умолчанию: True
Значение по умолчанию: False
Использование:
Чтобы создать, включите шаблоны данных только для системного диска:
Чтобы создать правило для сбора файлов для зарегистрированных расширений из каталога %PROGRAMFILES%:
Для создания исключений шаблонов данных:
Понимание контекста системы и пользователя
XML-файлы переноса содержат два с различными настройками контекста. **** Контекст системы применяется к файлам на компьютере, которые не хранятся в каталоге профилей пользователей, в то время как пользовательский контекст применяется к файлам, которые являются конкретными для отдельного пользователя.
Контекст системы
Контекст системы включает правила для данных за пределами каталога профилей пользователей. Например, при призыве в системный контекст в MigDocs.xml файле функция GenerateDocPatterns создает шаблоны для всех общих папок оболочки, файлов в корневом каталоге жестких дисков и папок, расположенных в корневых жестких дисках. В список включены следующие папки:
Контекст пользователя
Контекст пользователя содержит правила для данных в каталоге профилей пользователей. При призыве в контексте пользователя в MigDocs.xml файле функция GenerateDocPatterns создает шаблоны для всех папок оболочки пользователей, файлов, расположенных в корне профиля, и папок, расположенных в корне профиля. В список включены следующие папки:
Правила, содержащиеся в компоненте, назначенном пользовательскому контексту, будут запускаться для каждого профиля пользователя на компьютере. Файлы, сканированные несколько раз MigDocs.xml, будут скопированы в хранилище миграции только один раз; однако большое количество правил в пользовательском контексте может замедлить миграцию. Используйте системный контекст, если он применим.
Пример правил миграции для настраиваемых версий XML-файлов
Лучшие практики и требования к настраиваемым XML-файлам в USMT см. в материалах Customize USMT XML Files and General Conventions.
Исключение примеров использования правил
Правило | Синтаксис |
---|---|
Правило 1 |