2016-07-04 12 views
2

Как .NET Native toolchain обрабатывает управляемые библиотеки компонентов .winmd подробно?Универсальные библиотеки компонентов Windows и родной Winmd

Я знаю, что .NET Native объединяет весь управляемый код из DLL в один исполняемый файл и удаляет неиспользуемый код при компиляции его в native.

Но какой алгоритм используется для управляемых библиотек .winmd? Например, фоновые задачи (например, фоновое фоновое задание) в WinRT размещаются в библиотеке winmd, а затем эти задачи размещаются в системном собственном процессе, который динамически вызывает классы, предоставленные winmd. Как это совместимо с концепцией .NET Native?

Я беспокоюсь, что .NET Native может не преобразовывать управляемый .winmd-код в native и среду, будет отвисеть от среды выполнения .NET для выполнения кода в управляемом winmd, поэтому отказ от преимуществ собственного скомпилированного исполняемого файла. Или как это работает?

Пожалуйста, предоставьте информацию об этом не очень понятном материале. В документации MSDN нет подробной информации об управляемых библиотеках компонентов winmd и .NET Native toolchain.

+1

Это просто метаданные, не отличаются вообще из метаданных .NET в сборки .NET. Он описывает типы, экспортируемые из модуля. Кроме того, что он также работает для неуправляемого кода, вы также можете написать такую ​​фоновую задачу на C++. Фактически формат .winmd * точно * совпадает с форматом метаданных .NET, вы можете использовать декомпилятор .NET, например ildasm.exe, чтобы посмотреть на него. Ничего особенно мистического в этом, это «беспокойство» бессмысленно. –

+0

@HansPassant Мой вопрос в том, как он работает вместе с .NET-родной toolchain. –

ответ

2

Я работаю в родной команде .NET, и я буду рад помочь прояснить.

.NET native действительно преобразует управляемые сборки WinMD в собственный код и объединит его вместе с DLL приложения (на сегодняшний день). Чтобы процесс фоновой задачи мог найти собственный код для этих управляемых классов WinRT, мы также фиксируем манифест приложения, чтобы указать на DLL приложения, у которого теперь есть собственный код для них. Фоновый процесс задачи с удовольствием загрузит DLL приложения и активирует управляемые типы WinRT, реализованные в собственном коде, размещенном в DLL приложения, используя протокол активации WinRT/ABI. Не требуется JITting.

Как вы подозревали, есть некоторые интересные проблемы с поиском, какие классы WinRT активируются из собственного кода. Сегодня мы консервативно рассматриваем все общедоступные классы WinRT в управляемом WinMD как корни компиляции в родном компиляторе .NET и все, что доступно для них. Есть некоторые последствия в размере, но это компромисс с отсутствием JIT. не

Спасибо, Yi Zhang

+0

Спасибо за ответ. Теперь все ясно. –