WinRT Projected Typen Dokumentation

Question

Es gibt etwas, projiziert Typen in WinRT. Zum Beispiel in den Metadaten wird die IXamlType.UnderlyingType wie folgt definiert:

TypeName UnderlyingType { get; } 

jedoch, wenn sie in einer C# app verwendet, ändert sich wie folgt:

Type UnderlyingType { get; } 

Meine Frage ist - gibt es eine Dokumentation in Bezug auf die Regeln , API, Attribute für solche Mappings?

Answer 1

Das stimmt, die Sprachprojektion, die in die CLR integriert ist, ordnet WinRT-Typen automatisch CLR-Typen zu. Dokumentation ist schwer zu bekommen, besonders jetzt, wenn dies noch Beta-Material ist. Aber es gibt ein exzellentes White Paper, das einige Aspekte der CLR-Projektion beschreibt. Der Download ist (derzeit) available here (Hinweis: Word DOCX-Datei)

Answer 2

Dies ist der Link, über den ich sprach, der ein Video auf Kanal 9 ist http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-874T Bitte beachten Sie, dass dies ein Video der Build-Konferenz ist, die auf der Developer Preview basiert. Ich kann nicht vorhersagen, wie viel von dieser Information sich mit der Verbrauchervorschau geändert hat.

Ich stimme zu, dass es Dokumentation darüber geben sollte, wie das funktioniert. Hoffentlich werden sie die Dokumentation auf MSDN bald aktualisieren.

Answer 3

Wenn Windows-Metadaten mit den Low-Level-Authoring-Tools (MIDL mit der/Winrt-Schalter und MDMERGE) erstellt werden, alle Orte in der Assembly, die normalerweise verwendet würden ein typedef, der typedef wird durch typerefs ersetzt, die in dieselbe Assembly zeigen.

Dadurch kann die CLR den Inhalt der winmd-Datei neu schreiben und den Windows-Laufzeittyp durch einen entsprechenden CLR-Typ ersetzen. Das einfachste Beispiel hierfür ist der Windows.Foundation.Uri-Typ, der durch System.Uri in C# -Anwendungen ersetzt wird. Die CLR weiß intern, wie zwischen W.F.Uri und S.Uri zu mappen ist und führt automatisch diese Übersetzung für Sie durch.

All dies wird automatisch vom System gehandhabt, es gibt Regeln dafür, aber ich glaube nicht, dass der Prozess vom Entwickler steuerbar ist - ich glaube, dass die Typzuordnungen in die CLR-Implementierung gebrannt werden.

Answer 4

Sie sagen, dass der Quellcode die beste Dokumentation ist. In diesem Fall scheint es die einzige Dokumentation zu sein. Hier sind meine Ergebnisse von Spelunking durch die .NET-Quelle.

Die Liste der Metadatenprojektionen ist im Format codiert.

Dieser Header ist an verschiedenen Stellen enthalten, wo er in Datenstrukturen für die jeweilige Aufgabe umgewandelt wird. Der zugänglichste Ort für uns, den ich gefunden habe, ist in der WinMD metadata importer und seine adapter. Von der Quelle:

// This metadata importer is exposed publically via CoCreateInstance(CLSID_CorMetaDataDispenser...). 
// when the target is a .winmd file. It applies a small number of on-the-fly 
// conversions to make the .winmd file look like a regular .NET assembly. 

Meine Meinung ist, dass Sie CoCreateInstance(CLSID_CorMetaDataDispenser...) können eine IMetaDataDispenser, rufen OpenScope() mit IID_IMetaDataImport mit einer .winmd-Datei zu erhalten, die Metadaten Importeur zu erstellen. Es wird dann Konvertierungen wie IMap zu IDictionary für Sie tun, wie Sie die Metadaten durchlesen. Ich spekuliere, aber ich bin mir ziemlich sicher, dass das Visual Studio beim Generieren von Typdefinitionen aus Metadaten- oder Schnittstellenimplementierungen tut.

Sie können auch den Header mit dem Makro-Iterator in Ihr eigenes C/C++ - Projekt einfügen und die darin enthaltenen Daten in die für Sie am besten geeignete Form umwandeln, z. Code daraus generieren.