Ngen.exe (генератор собственных образов)

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

Изменения Ngen.exe в .NET Framework 4:

• Ngen.exe теперь компилирует сборки с полным доверием, а политика безопасности доступа к коду больше не вычисляется.

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

Изменения Ngen.exe в .NET Framework версии 2.0:

• Установка сборки также устанавливает его зависимости, упрощая синтаксис Ngen.exe.

• Теперь собственные образы можно совместно использовать между доменами приложений.

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

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

• Некоторые причины недопустимости изображения были устранены.

В Windows 8 см. задачу "Собственный образ".

Дополнительные сведения об использовании Ngen.exe и собственной службе образов см. в статье "Собственная служба образов".

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

Введите в командной строке: .

Синтаксис

ngen action [options]

ngen /? | /help

Действия

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

Arguments

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

Сценарии

Config

Options

Замечания

Чтобы запустить Ngen.exe, необходимо иметь права администратора.

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

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

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

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

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

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

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

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

В этом разделе "Примечания":

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

• Определение того, когда следует использовать собственные образы

  • Улучшенное использование памяти

  • Ускорение запуска приложения

  • Сводка рекомендаций по использованию

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

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

  • Указание указания привязки для зависимости

  • Указание указания привязки по умолчанию для сборки

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

• Собственные образы и компиляция JIT

  • Недопустимые изображения

• Troubleshooting

  • Средство просмотра журналов привязки сборок

  • Помощник по отладке управляемого запуска JITCompilationStart

  • Отказ от создания собственного образа

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

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

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

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

Определение того, когда следует использовать собственные образы

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

Улучшенное использование памяти

Собственные образы могут значительно улучшить использование памяти при совместном использовании кода между процессами. Собственные образы — это файлы windows PE, поэтому одна копия файла .dll может совместно использоваться несколькими процессами; В отличие от этого, машинный код, созданный компилятором JIT, хранится в частной памяти и не может быть предоставлен общий доступ.

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

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

Ускорение запуска приложения

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

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

Сводка рекомендаций по использованию

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

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

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

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

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

• Собственные образы должны поддерживаться.

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

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

  • Собственные образы должны создаваться администратором; то есть из учетной записи Windows в группе "Администраторы".

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

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

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

  Замечание

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

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

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

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

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

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

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

Вы можете использовать средство, например dumpbin.exe, чтобы просмотреть предпочтительный базовый адрес собственного образа.

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

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

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

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

Указание указания привязки для зависимости

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

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

Imports System.Runtime.CompilerServices
<Assembly:DependencyAttribute("Assembly1", LoadHint.Always)>
<Assembly:DependencyAttribute("Assembly2", LoadHint.Sometimes)>

using System.Runtime.CompilerServices;
[assembly:DependencyAttribute("Assembly1", LoadHint.Always)]
[assembly:DependencyAttribute("Assembly2", LoadHint.Sometimes)]

using namespace System::Runtime::CompilerServices;
[assembly:DependencyAttribute("Assembly1", LoadHint.Always)];
[assembly:DependencyAttribute("Assembly2", LoadHint.Sometimes)];

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

Указание указания привязки по умолчанию для сборки

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

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

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

Создание собственных образов для очень большого приложения может занять значительное время. Аналогичным образом изменения общего компонента или изменения параметров компьютера могут потребовать обновления множества собственных образов. update Действия install имеют /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 автоматически создает собственные образы для установленных библиотек .NET Framework.

• Точное удостоверение сборки.

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

• Точное удостоверение любых сборок, ссылаемых на сборки.

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

• Факторы безопасности.

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

  Подробные сведения о том, как среда CLR управляет безопасностью доступа к коду и способом использования разрешений, см. в разделе "Безопасность доступа к коду".

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

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

Средство просмотра журналов привязки сборок

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

Помощник по отладке управляемого запуска JITCompilationStart

С помощью помощника по отладке jitCompilationStart (MDA) можно определить, когда компилятор JIT начинает компиляцию функции.

Отказ от создания собственного образа

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

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

namespace System.Runtime
{
   [AttributeUsage(AttributeTargets.Method |
                   AttributeTargets.Constructor |
                   AttributeTargets.Property)]
   public class BypassNGenAttribute : Attribute
   {
   }
}

Namespace System.Runtime
    <AttributeUsage(AttributeTargets.Method Or
                    AttributeTargets.Constructor Or
                    AttributeTargets.Property)>
    Public Class BypassNGenAttribute : Inherits Attribute
    End Class
End Namespace

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

using System;
using System.Runtime;

public class ExampleClass
{
   [BypassNGen]
   public void ToJITCompile()
   {
   }
}

Imports System.Runtime

Public Class ExampleClass
    <BypassNGen>
    Public Sub ToJITCompile()
    End Sub
End Class

Примеры

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

ngen install ClientApp.exe

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

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

ngen install c:\myfiles\MyAssembly.exe

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

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

ngen install c:\myfiles\MyLib.dll /ExeConfig:c:\myapps\MyApp.exe

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

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

ngen uninstall c:\myfiles\MyLib.dll /ExeConfig:c:\myapps\MyApp.exe

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

ngen install "ClientApp, Version=1.0.0.0, Culture=neutral,
  PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL"

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

ngen install MyApp.exe
ngen install MyApp.exe /debug
ngen install MyApp.exe /profile

Отображение собственного кэша образов

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

ngen display

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

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

ngen display MyAssembly

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

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

ngen display c:\myApps\MyAssembly.exe

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

ngen display "myAssembly, version=1.0.0.0"

Обновление изображений

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

ngen update

Обновление всех изображений может быть длительным процессом. Обновления для выполнения собственной службой образов можно в очереди, используя /queue этот параметр. Дополнительные сведения о /queue параметрах и приоритетах установки см. в разделе "Собственная служба образов".

ngen update /queue

Удаление образов

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

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

ngen uninstall ClientApp

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

ngen uninstall ClientApp /debug

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

ngen uninstall "ClientApp, Version=1.0.0.0"

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

ngen uninstall "ClientApp, Version=1.0.0.0, Culture=neutral,
  PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL"
ngen uninstall "ClientApp, Version=1.0.0.0, Culture=neutral,
  PublicKeyToken=3c7ba247adcd2081, processorArchitecture=MSIL" /debug

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

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

Задача "Собственный образ"

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

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

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

Время существования задачи

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

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

Собственная служба образов

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

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

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

Запуск отложенных операций

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

ngen queue pause

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

ngen queue continue

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

ngen install MyComponent /queue
ngen update /queue

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

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

ngen install Assembly1 /queue:1
ngen install Assembly2 /queue:2
ngen install Assembly3 /queue:3

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

ngen executeQueuedItems

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

Завершение работы службы

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

Взаимодействие со службами с клиентами

В .NET Framework версии 2.0 единственным взаимодействием со службой собственных образов является средство командной строки Ngen.exe. Используйте средство командной строки в сценариях установки для очередей действий для собственной службы образов и взаимодействия со службой.

См. также

• Инструменты
• Процесс управляемого выполнения
• Как среда выполнения находит сборки
• Оболочки командной строки для разработчиков