.NET Native и компиляция

Настольные приложения Windows, предназначенные для .NET Framework, написаны на определенном языке программирования и компилируются в промежуточный язык (IL). Во время выполнения JIT-компилятор отвечает за компиляцию IL в машинный код для локального компьютера непосредственно перед первым выполнением метода. В отличие от этого, цепочка инструментов .NET Native преобразует исходный код в машинный код во время компиляции. В этой статье сравнивается .NET Native с другими технологиями компиляции, доступными для приложений .NET Framework, а также предоставляется практический обзор того, как .NET Native создает машинный код, который поможет понять, почему исключения, происходящие в коде, скомпилированном с помощью .NET Native, не происходят в скомпилированном JIT-коде.

Создание нативных двоичных файлов

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

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

  • Код реализации. Состоит из опкодов промежуточного языка (IL). Во время выполнения компилятор JIT преобразует его в машинный код для целевой платформы.

Помимо основной сборки приложения, приложению требуется следующее:

  • Любые дополнительные библиотеки классов или сторонние сборки, необходимые вашему приложению. Эти сборки также включают метаданные, описывающие сборку, её типы и их члены, а также IL, реализующий все члены типа.

  • Библиотека классов .NET Framework. Это коллекция сборок, установленных в локальной системе с установкой .NET Framework. Сборки, включенные в библиотеку классов .NET Framework, включают полный набор метаданных и кода реализации.

  • Общая среда выполнения (CLR). Это коллекция динамически подключаемых библиотек, которые выполняют такие службы, как загрузка сборок, управление памятью и сборка мусора, обработка исключений, компиляция JIT (just-in-time), взаимодействие с удаленными системами и межъязыковое взаимодействие. Как и библиотека классов, среда выполнения устанавливается в локальной системе в рамках установки .NET Framework.

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

JIT-компиляция

Входные данные для цепочки инструментов .NET Native — это приложение UWP, созданное компилятором C# или Visual Basic. Другими словами, цепочка инструментов .NET Native начинает выполнение, когда компилятор языка завершит компиляцию приложения UWP.

Подсказка

Так как входные данные в .NET Native — это IL и метаданные, записанные в управляемые сборки, вы по-прежнему можете выполнять создание пользовательского кода или другие пользовательские операции с помощью событий предварительной сборки или после сборки или изменения файла проекта MSBuild.

Однако категории инструментов, которые изменяют IL и тем самым предотвращают анализ IL приложения в цепочке инструментов .NET, не поддерживаются. Обфускаторы являются наиболее заметными инструментами этого типа.

В ходе преобразования приложения из IL в машинный код цепочка инструментов .NET Native выполняет следующие операции:

  • Для некоторых путей кода он заменяет код, использующий отражение и метаданные, статическим машинным кодом. Например, если тип значения не переопределяет ValueType.Equals метод, тест по умолчанию для равенства использует отражение для получения FieldInfo объектов, представляющих поля типа значения, а затем сравнивает значения полей двух экземпляров. При компиляции в машинный код цепочка инструментов .NET Native заменяет код отражения и метаданные статическим сравнением значений полей.

  • По возможности она пытается устранить все метаданные.

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

  • Он заменяет полный CLR рефакторизованной средой выполнения, которая в основном содержит сборщик мусора. Рефакторированная среда выполнения находится в библиотеке под названием mrt100_app.dll, которая локальна для приложения и составляет всего несколько сотен килобайтов. Это возможно, так как статическое связывание устраняет потребность во многих службах, выполняемых средой CLR.

    Замечание

    В .NET Native используется тот же сборщик мусора, что и стандартная среда CLR. В сборщике мусора .NET Native фоновая сборка мусора включена по умолчанию. Дополнительные сведения о сборке мусора см. в разделе "Основы сборки мусора".

Это важно

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

Полученное приложение, созданное цепочкой инструментов .NET Native, записывается в директорию с именем ilc.out в директории Debug или Release внутри каталога вашего проекта. Он состоит из следующих файлов:

  • <appName>.exe— это заглушка, которая просто передает управление специальному экспорту Main в <appName>.dll.

  • <appName>.dll, динамическая библиотека ссылок Windows, содержащая весь код вашего приложения, а также код из библиотеки классов .NET Framework и любых сторонних библиотек, от которых вы зависите. Он также содержит код поддержки, например код, необходимый для взаимодействия с Windows и сериализации объектов в приложении.

  • mrt100_app.dll— рефакторированная исполняющая среда, предоставляющая службы, такие как сборка мусора.

Все зависимости фиксируются манифестом APPX приложения. Помимо exe приложения, dll и mrt100_app.dll, которые упаковываются непосредственно в пакет appx, это включает в себя еще два файла:

  • msvcr140_app.dll— библиотека времени выполнения C (CRT), используемая в mrt100_app.dll. Он включается ссылкой на платформу в пакете.

  • mrt100.dll. Эта библиотека включает функции, которые могут повысить производительность mrt100_app.dll, хотя его отсутствие не препятствует mrt100_app.dll функционированию. Он загружается из каталога system32 на локальном компьютере, если он присутствует.

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

  • Отражение.

  • Динамический или поздний вызов.

  • Сериализация и десериализация.

  • COM-взаимодействие.

Если необходимые метаданные или код реализации отсутствуют во время выполнения, среда выполнения .NET Native создает исключение. Эти исключения можно предотвратить и убедиться, что цепочка инструментов .NET Native включает необходимые метаданные и код реализации с помощью файла директив среды выполнения, XML-файл, указывающий элементы программы, метаданные или код реализации которых должны быть доступны во время выполнения и назначает политику выполнения. Ниже приведен файл директив среды выполнения по умолчанию, который добавляется в проект UWP, скомпилированный цепочкой инструментов .NET Native:

<Directives xmlns="http://schemas.microsoft.com/netfx/2013/01/metadata">
  <Application>
    <Assembly Name="*Application*" Dynamic="Required All" />
  </Application>
</Directives>

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

См. также

  • Последнее обновление: