W programie WinRT wyświetlanych jest coś o nazwie wyświetlanych typów. Na przykład w metadanych The IXamlType.UnderlyingType jest zdefiniowany jako:Dokumentacja typów przewidywanych WinRT
TypeName UnderlyingType { get; }
Jednak gdy używany w aplikacji C#, zmienia się w następujący sposób:
Type UnderlyingType { get; }
Moje pytanie brzmi - czy istnieje jakaś dokumentacja dotycząca zasad , API, atrybuty używane do takich mapowań?
Zgadza się, wersja językowa wbudowana w CLR automatycznie odwzorowuje typy WinRT na typy CLR. Trudno jest dotrzeć do dokumentacji, szczególnie teraz, gdy wciąż jest to materiał beta. Ale dostępna jest doskonała biała księga opisująca niektóre aspekty projekcji CLR. Pobranie to (obecnie) available here (Uwaga: plik Word .docx)
To jest link, o którym mówiłem, który jest filmem na kanale 9 http://channel9.msdn.com/Events/BUILD/BUILD2011/PLAT-874T Należy zauważyć, że jest to wideo konferencji Build, która jest oparta na podglądzie programisty. Nie mogę przewidzieć, jak wiele z tych informacji zmieniło się w podglądzie klienta.
Zgadzam się, że powinna istnieć dokumentacja na temat tego, jak to działa. Mam nadzieję, że wkrótce zaktualizują dokumentację w MSDN.
Gdy metadane systemu Windows są tworzone za pomocą narzędzi do authoringu niskiego poziomu (MIDL z przełącznikiem/winrt i MDMERGE), dowolne miejsca w zestawie, które normalnie używają typedef, typedef jest zastępowany typerefami, które wskazują wewnątrz tego samego zestawu.
Dzięki temu CLR może przepisać zawartość pliku winmd, zastępując typ środowiska wykonawczego Windows odpowiednim typem CLR. Najprostszym przykładem tego jest typ Windows.Foundation.Uri jest zastąpiony przez System.Uri do aplikacji C#. CLR wewnętrznie wie, jak mapować między W.F.Uri i S.Uri i automatycznie wykonuje to tłumaczenie dla ciebie.
Wszystko to jest obsługiwane automatycznie przez system, są na to reguły, ale nie wierzę, że proces jest kontrolowany przez programistę - wierzę, że odwzorowania typów są wypalane w implementacji CLR.
Dzięki za informacje. Jest w porządku, ale jeśli proces nie jest kontrolowany przez dev, ale dokumentacja samego procesu byłaby świetna! – logicnp
Mówią, że kod źródłowy jest najlepszą dokumentacją. W tym przypadku wydaje się, że jest to jedyna dokumentacja. Oto moje odkrycia od spelunkowania przez źródło .NET.
Lista projekcji metadanych jest zakodowana w .NET source using a macro iterator.
Ten nagłówek znajduje się w różnych miejscach, w których jest przekształcany w struktury danych dla danego zadania. Najbardziej dostępne miejsce dla nas, które znalazłem, to WinMD metadata importer i jego adapter. Od źródła:
// 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.
My się to, że można używać CoCreateInstance(CLSID_CorMetaDataDispenser...) stworzyć IMetaDataDispenser, zadzwoń OpenScope() z IID_IMetaDataImport z plikiem .winmd dostać importera metadanych. Następnie wykona konwersje, takie jak IMap do IDictionary, gdy przejrzysz metadane. Spekuluję, ale jestem prawie pewien, że to właśnie robi Visual Studio podczas generowania definicji typów z metadanych lub implementacji interfejsu.
Możesz również dołączyć nagłówek z iteratorem makr do swojego własnego projektu C/C++ i przekształcić dane w dowolną formę najbardziej przydatną dla ciebie, np. wygenerować z niego kod.
Nie można znaleźć żadnej dokumentacji na ten temat. Widziałeś tylko kilka filmów na kanale 9, ale to chyba nie jest dla ciebie wystarczająco głębokie nurkowanie? Czy możesz przesłać ci linki, jeśli chcesz? – ChristiaanV
@ ChristhawanV - linki byłyby bardzo pomocne, dzięki. Jednakże kompletna i formalna dokumentacja w tym zakresie moja firma Microsoft byłaby niezwykle pomocna i jest konieczną IMHO. – logicnp