Ngen.exe (генератор образов в машинном коде)

Генератор образов в машинном коде (Ngen.exe) — это средство повышения быстродействия управляемых приложений. Программа Ngen.exe создает образы в машинном коде, представляющие собой файлы, содержащие компилированный, специфический для процессора машинный код, и устанавливает их в кэш образов в машинном коде на локальном компьютере. Среда выполнения может использовать образы в машинном коде, находящиеся в кэше, вместо использования JIT-компилятора для компиляции исходной сборки.

Ngen.exe компилирует образы в машинном коде для сборок, предназначенных только для .NET Framework. Аналогичным генератором образов в машинном коде для .NET Core является CrossGen.

Изменения в программе NGen.exe для .NET Framework 4:

Теперь программа NGen.exe компилирует сборки с полным доверием, и политика разграничения доступа кода (CAS) больше не вычисляется.

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

Изменения в программе NGen.exe для .NET Framework версии 2.0.

При установке сборки также устанавливаются ее зависимости, что упрощает синтаксис Ngen.exe.

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

Новое действие, update , заново создает образы, ставшие недействительными.

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

Были устранены некоторые причины недействительности образов.

Подробнее об использовании программы Ngen.exe и службы образов в машинном коде см. в разделе Служба образов в машинном коде.

Синтаксис Ngen.exe для .NET Framework версий 1.0 и 1.1 см. в разделе Генератор образов в машинном коде (Ngen.exe), традиционный синтаксис.

Эта программа автоматически устанавливается вместе с Visual Studio. Для запуска этого средства используйте Командную строку разработчика или PowerShell для разработчиков в Visual Studio.

В командной строке введите следующее.

Синтаксис

Действия

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

Аргументы

Аргумент Описание assemblyName Полное отображаемое имя сборки. Например, "myAssembly, Version=2.0.0.0, Culture=neutral, PublicKeyToken=0038abc9deabfle5" . Примечание. Для display действий и uninstall можно указать частичное имя сборки, например ,.

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

Уровни приоритета

Сценарии

Config

Конфигурация Описание /ExeConfig: exePath Используется конфигурация указанной исполняемой сборки.

Параметры

Примечания

Для запуска Ngen.exe требуются права администратора.

Не запускайте программу NGen.exe в сборках с неполным доверием. Начиная с .NET Framework 4, программа NGen.exe компилирует сборки с полным доверием, а политика управления доступом для кода (CAS) больше не вычисляется.

Начиная с .NET Framework 4 образы в машинном коде, созданные с помощью NGen.exe, нельзя загружать в приложения, выполняющиеся в режиме частичного доверия. Вместо этого вызывается JIT-компилятор.

Программа Ngen.exe создает образы в машинном коде для сборки, указанной аргументом assemblyname , для действия install и всех его зависимостей. Зависимости определяются по ссылкам в манифесте сборки. Единственный сценарий, в котором необходимо задавать зависимость отдельно, — это когда приложение загружает зависимость с помощью отражения, например путем вызова метода Assembly.Load.

Не используйте метод Assembly.LoadFrom с образами в машинном коде. Образ, загруженный этим методом, не может использоваться другими сборками в контексте выполнения.

Программа Ngen.exe ведет подсчет зависимостей. Например, пусть и MyAssembly.exe и YourAssembly.exe установлены в кэше образов в машинном коде и содержат ссылки на OurDependency.dll . При удалении MyAssembly.exe библиотека OurDependency.dll не удаляется. Она удаляется только после удаления YourAssembly.exe .

При создании образа в машинном коде для сборки из глобального кэша сборок необходимо указать ее отображаемое имя. См. раздел Assembly.FullName.

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

Примените к своему приложению атрибут LoaderOptimizationAttribute.

При создании сведений о настройке для нового домена приложений задайте свойство AppDomainSetup.LoaderOptimization.

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

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

В этом разделе примечаний

Формирование образов для различных сценариев

После создания образа в машинном коде для сборки среда выполнения автоматически пытается обнаружить и использовать этот образ в машинном коде при каждом запуске сборки. В зависимости от сценариев использования может быть создано несколько образов.

Например, при запуске сборки в рамках сценария отладки или профилирования среда выполнения ищет образ в машинном коде, созданный с параметрами /Debug или /Profile . Если найти соответствующий образ в машинном коде не удается, среда выполнения возвращается к стандартной схеме JIT-компиляции. Единственным способом отладки образов в машинном коде является создание образа в машинном коде с параметром /Debug .

Действие uninstall также распознает сценарии, позволяя удалить все или только выбранные сценарии.

Определение случаев использования образов в машинном коде

Образы в машинном коде могут повысить производительность в двух областях: оптимизация использования памяти и уменьшение времени запуска.

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

Использование образов в машинном коде может заметно повысить эффективность использования памяти в ситуациях, когда код используется одновременно несколькими процессами. Образы в машинном коде являются файлами Windows PE, поэтому несколько процессов могут совместно использовать одну копию DLL-файла. Напротив, образ в машинном коде, созданный JIT-компилятором, хранится в выделенной памяти и не может быть использован совместно.

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

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

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

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

До .NET Framework 3.5 с пакетом обновления 1 (SP1) необходимо было помещать общие компоненты со строгими именами в глобальный кэш сборок, так как загрузчик выполняет дополнительную проверку сборок со строгими именами, отсутствующих в глобальном кэше сборок, фактически сводя на нет уменьшение времени запуска, создаваемое за счет использования образов в машинном коде. За счет ряда усовершенствований, которые впервые появились в NET Framework 3.5 SP1, была исключена дополнительная проверка.

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

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

За счет устранения JIT-компилятора из процесса разработки образы в машинном коде требуют меньшего первоначального объема работы.

Образы в машинном коде обеспечивают совместное использование кода несколькими процессами.

Образам в машинном коде требуется больше места на жестком диске по сравнению со сборками CIL. Кроме того, их создание может занимать значительное время.

Образы в машинном коде необходимо обслуживать.

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

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

Образы в машинном коде должны создаваться администратором, то есть под учетной записью Windows в группе "Администраторы".

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

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

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

В .NET Framework версий 1.0 и 1.1 совместное использование образов в машинном коде в нескольких доменах приложений невозможно. Однако в версии 2.0 и более поздних версиях ситуация изменилась.

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

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

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

Важность базовых адресов сборок

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

Чтобы задать базовый адрес для образа в машинном коде, с помощью соответствующего параметра компилятора можно задать базовый адрес сборки. Программа Ngen.exe использует этот базовый адрес для образа в машинном коде.

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

Для просмотра предпочитаемого базового адреса образа в машинном коде можно использовать такую программу, как dumpbin.exe.

Жесткая привязка

Жесткая привязка увеличивает производительность и уменьшает объем работы для образов в машинном коде. Недостаток жесткой привязки состоит в том, что при загрузке сборки должны загружаться все образы, жестко привязанные к сборке. Для большого приложения это может заметно увеличить время запуска.

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

Атрибуты DependencyAttribute и DefaultDependencyAttribute позволяют предоставить программе Ngen.exe подсказки, касающиеся жесткой привязки.

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

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

В следующем коде показаны атрибуты для сборки с двумя зависимостями. Первая зависимость (Assembly1) является подходящим кандидатом для жесткой привязки, а вторая (Assembly2) — нет.

Имя сборки не включает в себя расширение имени файла. Разрешается использовать отображаемые имена.

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

Не стоит применять атрибут DefaultDependencyAttribute к DLL-сборкам, не подпадающим под эту категорию, поскольку применение атрибута с любым значением, отличным от LoadHint.Always, аналогично полному отсутствию атрибута.

Корпорация Майкрософт использует атрибут DefaultDependencyAttribute для указания того, что жесткая привязка является значением по умолчанию для очень небольшого числа сборок в .NET Framework, например "mscorlib.dll".

Отложенная обработка

Создание образов в машинном коде для очень большого приложения может занять значительное время. Аналогичным образом, изменения общего компонента или настроек компьютера могут потребовать обновления многих образов в машинном коде. Для действий install и update предусмотрен параметр /queue , который помещает операцию в очередь для отложенного выполнения службой образов в машинном коде. Кроме того, программа Ngen.exe предусматривает действия queue и executeQueuedItems , которые дают определенные возможности управления этой службой. Подробнее см. в разделе Служба образов в машинном коде.

Образы в машинном коде и JIT-компиляция

Если программа Ngen.exe обнаруживает в сборке методы, которые она не может создать, эти методы исключаются из этого образа. Когда среда выполнения выполняет сборку, то при обнаружении метода, отсутствующего в образе в машинном коде, выполняется JIT-компиляция.

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

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

Версия .NET Framework.

Полное удостоверение сборки (оно изменяется при перекомпиляции).

Полное удостоверение всех сборок, на которые ссылается данная сборка (оно изменяется при перекомпиляции).

Программа Ngen.exe сохраняет эти сведения при создании образа в машинном коде. При выполнении сборки среда выполнения просматривает созданный образ в машинном коде на предмет таких параметров и сравнивает их с текущими параметрами среды компьютера. Если среда выполнения не находит соответствующий образ в машинном коде, выполняется JIT-компиляция. Изменения следующих параметров компьютера и среды приводят к тому, что образы устаревают, то есть становятся непригодными для использования.

Версия .NET Framework.

При обновлении .NET Framework все образы в машинном коде, созданные с помощью Ngen.exe, становятся недействительными. По этой причине, чтобы обеспечить повторное создание всех образов в машинном коде, все обновления .NET Framework выполняют команду Ngen Update . Платформа .NET Framework автоматически создает новые образы в машинном коде для устанавливаемых ею библиотек.

Полное удостоверение сборки.

При перекомпиляции сборки соответствующий образ в машинном коде устаревает.

Полное удостоверение всех сборок, на которые ссылается данная сборка.

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

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

Подробную информацию об управлении доступом для кода в среде CLR и об использовании разрешений см. в разделе Управление доступом для кода.

Устранение неполадок

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

Проверить, используются ли в приложении образы в машинном коде, можно с помощью Fuslogvw.exe (средства просмотра журнала привязок сборки). Выберите Образы в машинном коде в поле Категории журнала в окне средства просмотра журнала привязок. Программа Fuslogvw.exe предоставляет сведения о причинах отклонения образа в машинном коде.

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

В некоторых случаях NGen.exe может испытывать трудности при создании образа в машинном коде для конкретного метода. Кроме того, может быть удобнее выполнить JIT-компиляцию метода вместо компиляции в образ в машинном коде. В этом случае можно использовать атрибут System.Runtime.BypassNGenAttribute , чтобы запретить программе NGen.exe формирование образа в машинном коде для конкретного метода. Атрибут необходимо применять по отдельности к каждому методу, код которого не нужно включать в образ в машинном коде. NGen.exe распознает атрибут и не создает код в образе в машинном коде для соответствующего метода.

Тем не менее обратите внимание, что BypassNGenAttribute не определен как тип в библиотеке классов .NET Framework. Для использования атрибута в коде, его необходимо сначала определить следующим образом.

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

Примеры

Следующая команда создает образ в машинном коде для приложения ClientApp.exe , расположенного в текущем каталоге, и устанавливает образ в кэш образов в машинном коде. Если для сборки существует файл конфигурации, программа Ngen.exe использует его. Кроме того, образы в машинном коде создаются для всех DLL-файлов, на которые ссылается программа ClientApp.exe .

Образ, установленный с программой Ngen.exe, также называется корнем. Корень может быть приложением или общим компонентом.

Следующая команда создает образ в машинном коде для MyAssembly.exe с указанным путем.

При поиске сборок и их зависимостей программа Ngen.exe использует ту же самую логику тестирования, что и среда CLR. По умолчанию каталог, содержащий приложение ClientApp.exe , используется в качестве базового каталога приложения, с которого начинается тестирование всех сборок. Это поведение можно переопределить с помощью параметра /AppBase .

Поведение программы Ngen.exe было изменено по сравнению с .NET Framework версий 1.0 и 1.1, где в качестве базового каталога приложения использовался текущий каталог.

Сборка может использовать зависимость без ссылки, например, если она загружает DLL-файл с помощью метода Assembly.Load. С помощью параметра /ExeConfig для такого DLL-файла можно создать образ в машинном коде, используя сведения о конфигурации для сборки приложения. Следующая команда создает образ в машинном коде для MyLib.dll, , используя сведения о конфигурации из MyApp.exe .

Сборки, установленные таким способом, не удаляются при удалении приложения.

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

Чтобы создать образ в машинном коде для сборки в глобальном кэше сборок, следует использовать отображаемое имя сборки. Пример:

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

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

Действие display выводит сначала все корневые сборки, а затем выводит список всех образов в машинном коде на компьютере.

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

Знание того, что корни зависят от общей сборки компонентов, полезно при определении влияния действия update после обновления общего компонента.

Если задано расширение файла сборки, необходимо либо указать путь, либо выполнить программу Ngen.exe из каталога, в котором находится сборка.

Следующая команда выводит все образы в машинном коде с именем MyAssembly и версией 1.0.0.0, содержащиеся в кэше образов в машинном коде.

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

Обновление всех образов может занять длительное время. С помощью параметра /queue можно поставить обновления в очередь выполнения службы образов в машинном коде. Дополнительные сведения /queue о параметрах и приоритетах установки см. в разделе /queue .

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

Следующая команда удаляет все сценарии для корня ClientApp.exe :

Удалить конкретные сценарии можно с помощью действия uninstall . Следующая команда удаляет все сценарии отладки для ClientApp.exe :

При удалении сценариев /debug не удаляется сценарий, включающий и /profile , и /debug.

Следующая команда удаляет все сценарии для конкретной версии ClientApp.exe :

Следующая команда удаляет все сценарии для "ClientApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL", или только сценарий отладки для этой сборки.

Как и в случае действия install , предоставление расширения требует либо выполнения программы Ngen.exe из каталога, содержащего сборку, либо указания полного пути.

Примеры, связанные со службой образов в машинном коде, см. в разделе Служба образов в машинном коде.

Задача образов в машинном коде

Задача образов в машинном коде — это задача Windows, которая создает и поддерживает образы в машинном коде. Задача образов в машинном коде автоматически создает и освобождает образы в машинном коде в поддерживаемых сценариях. Она также позволяет установщикам использовать программу Ngen.exe (генератор образов в машинном коде) для отложенного создания и обновления образов в машинном коде.

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

Имя задачи 32-разрядный компьютер 64-разрядный компьютер NET Framework NGEN v4.0.30319 да да NET Framework NGEN v4.0.30319 64 Нет Да

Задача образов в машинном коде доступна в .NET Framework 4.5 и более поздних версий при выполнении в ОС Windows 8 или более поздних версий. В более ранних версиях Windows платформа .NET Framework использует службу образов в машинном коде.

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

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

Служба образов в машинном коде

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

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

Служба также взаимодействует с командой Ngen.exe, выполняемой вручную. Команды, выполняемые вручную, имеют приоритет над фоновыми действиями.

В операционной системе Windows Vista служба образов в машинном коде имеет имя "Microsoft.NET Framework NGEN v2.0.50727_X86" или "Microsoft.NET Framework NGEN v2.0.50727_X64". Во всех более ранних версиях Microsoft Windows ее имя — ".NET Runtime Optimization Service v2.0.50727_X86" или ".NET Runtime Optimization Service v2.0.50727_X64".

Перед началом установки или обновления рекомендуется приостановить службу. Это позволит заблокировать ее на время, пока установщик будет копировать файлы или помещать сборки в глобальный кэш сборок. Для приостановки службы используется следующая командная строка Ngen.exe:

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

Чтобы отложить создание образов в машинном коде при установке нового приложения или обновлении общего компонента, используйте параметр /queue с действием install или update . Следующие командные строки Ngen.exe позволяют установить образ общего компонента в машинном коде и выполнить обновление всех корней, которых это может касаться:

Действие update заново создает все образы в машинном коде, которые стали недействительными, а не только те, которые используют MyComponent .

Если в приложении слишком много корней, можно учитывать приоритеты отложенных действий. Приведенные ниже команды создают очередь для установки трех корней. Первой устанавливается сборка Assembly1 , не дожидаясь периода бездействия. Сборка Assembly2 также устанавливается без ожидания бездействия, но после завершения всех действий с приоритетом 1. Сборка Assembly3 устанавливается, когда служба обнаруживает, что компьютер бездействует.