2016-07-04 27 views
2

Wie .NET Native Toolchain verwaltete .winmd-Komponentenbibliotheken im Detail behandeln?Universal Windows .NET Native und Winmd-Komponentenbibliotheken

Ich weiß, dass .NET Native alle verwalteten Code aus DLLs in eine ausführbare Datei zusammenführen und entfernen Sie nicht verwendeten Code beim Kompilieren in native.

Aber welcher Algorithmus wird für .winmd verwalteten Bibliotheken verwendet? Zum Beispiel werden Hintergrundaufgaben (z. B. eine Audio-Hintergrundaufgabe) in WinRT in der winmd-Bibliothek gehostet, und dann werden diese Aufgaben innerhalb des systemeigenen nativen Prozesses gehostet, der die von winmd bereitgestellten Klassen dynamisch aufruft. Wie ist es kompatibel mit .NET Native-Konzept?

Ich mache mir Sorgen, dass .NET Native verwalteten .winmd-Code möglicherweise nicht in native konvertiert und die Umgebung auf die .NET-Laufzeit zurückgreift, um Code in verwaltetem winmd auszuführen, wodurch die Vorteile nativer kompilierter ausführbarer Dateien aufgegeben werden. Oder wie funktioniert es?

Bitte geben Sie Informationen zu dieser nicht so klaren Angelegenheit. In der MSDN-Dokumentation gibt es keine detaillierten Informationen zu verwalteten Winmd-Komponentenbibliotheken und .NET Native Toolchain.

+1

Es ist nur Metadaten, nicht anders als bei allen von .NET-Metadaten in einer .NET-Assembly. Es beschreibt die aus einem Modul exportierten Typen. Außer dass es auch für nicht verwalteten Code funktioniert, können Sie eine solche Hintergrundaufgabe auch in C++ schreiben. Tatsächlich ist das Format einer .winmd * genau * das gleiche wie das Format von .NET-Metadaten. Sie können einen .NET-Decompiler wie ildasm.exe verwenden, um ihn zu betrachten. Nichts besonders Mystisches daran, diese "Sorge" ist unsinnig. –

+0

@HansPassant Meine Frage ist, wie es zusammen mit .NET Native Toolchain funktioniert. –

Antwort

2

Ich arbeite bei .NET native Team und ich werde gerne helfen zu klären.

.NET native konvertiert tatsächlich verwaltete WinMD-Assemblies in systemeigenen Code und führt sie zusammen mit der App-DLL (ab heute) zusammen. Damit der Hintergrundtaskprozess den systemeigenen Code für diese verwalteten WinRT-Klassen findet, beheben wir auch das App-Manifest so, dass es auf die Anwendungs-DLL verweist, die jetzt über systemeigenen Code für sie verfügt. Der Task-Hintergrundprozess würde die App-DLL gerne laden und verwaltete WinRT-Typen aktivieren, die in nativem Code implementiert sind, der in der App-DLL gehostet wird, unter Verwendung des WinRT-Aktivierungsprotokolls/ABI. Kein JITting ist erforderlich.

Wie Sie vermutet haben, gibt es einige interessante Herausforderungen bei der Suche, welche WinRT-Klassen aus nativem Code aktiviert werden. Heute behandeln wir konservativ alle öffentlichen WinRT-Klassen in verwaltetem WinMD als Kompilierungsverzeichnisse im .NET-nativen Compiler und alles, was von ihnen aus erreichbar ist. Es gibt einige Auswirkungen auf die Größe, aber das ist der Kompromiss, keine JIT verfügbar zu haben.

Danke, Yi Zhang

+0

Danke für die Antwort. Jetzt ist alles klar. –