Ich brauche einige Metadaten über die Assembly, die meine Komponente aufruft. Daher scheint Assembly.GetCallingAssembly() eine natürliche Anpassung zu sein. Ich habe jedoch festgestellt, dass es überall funktioniert, außer im Windows Store. Wo es unterstützt wird:
Allerdings wird es nicht direkt in einer Windows Store-Anwendung unterstützt. Ich kann eine portable Klassenbibliothek erstellen und sie von dort aus in einer Windows Store-Anwendung aufrufen, aber ich kann sie nicht direkt in die Windows Store-App / Klassenbibliothek einfügen.
Gibt es eine Problemumgehung für diese oder eine andere Möglichkeit, den Typ der von Assembly bereitgestellten Metadaten abzurufen?
Assembly.GetCallingAssembly ist in WinRT nicht verfügbar - angeblich, weil seine Semantik angesichts von Inlining usw. unzuverlässig ist ( source ), aber es passt auch nicht zu sehr in die eingeschränkte Reflektion, die in Windows Store-Apps erlaubt ist. Du kannst etwas wie Assembly.GetCurrentAssembly() bekommen, zB so:
Aber das ist nicht das Gleiche. Mit dem Restricted-Reflection-Modell ist es auch nicht möglich, einen Stack-Trace zur Laufzeit zu erhalten, wie es in .NET möglich ist.
Was die portable Klassenbibliothek betrifft, wollte ich sagen, dass Assembly.GetCurrentAssembly() generell in portablen Klassenbibliotheken unterstützt wird, aber nur nicht in WinRT - was sinnvoll wäre, wenn es einfach nicht in dieser Plattform wäre. Aber tatsächlich scheint es, dass es in allen Profilen einschließlich WinRT mit Ausnahme von WinRT + .NET4.5 vorhanden ist - es scheint, dass es hier eine Art Überblick mit dieser Inkonsistenz geben muss. So ist die Methode in WinRT vorhanden (und außerdem gibt es keine Art von Umleitung), aber in den zur Kompilierzeit verfügbaren Metadaten nicht sichtbar.
Daher können Sie die Methode mit Reflektion aufrufen:
%Vor%Ich vermute, dass die Nichtsichtbarkeit dieser Methode in Windows Store-Apps ein "wir wünschen, dass dies weggehen würde" ist.
(Diese Antwort betrifft nur "kann ich" nicht "sollte ich").
Die Methode wurde einfach abgeschnitten, weil sie in einer WinRT-App zu unzuverlässig ist. Ein starkes Designziel für WinRT bestand darin, die Interoperabilität verschiedener Sprachlaufzeitumgebungen einfach und problemlos zu gestalten. Was gut funktioniert, Sie können einfach eine WinRT-Komponente in einer Sprache wie C # erstellen und sie von einer App verwenden lassen, die in einer nicht verwalteten Sprache wie C ++ oder Javascript geschrieben wurde.
Dies ist auch in einer Desktop-.NET-Anwendung möglich, aber es ist viel komplizierter, wenn Sie auf eine [ComVisible] -Assembly zurückgreifen oder eine Assembly im gemischten Modus in der C ++ / CLI-Sprache erstellen müssen. Wenn Assembly.GetCallingAssembly () in einem solchen Fall verwendet wird, wird dies ebenfalls fehlschlagen, es wird jedoch erwartet, dass es vom Programmierer nicht ausgeführt wird, da er sich bewusst ist, etwas Spezielles zu tun.
Das wird in einer WinRT-Komponente viel trüber. Zumal es nicht notwendig fehlschlägt, wenn der Aufruf tatsächlich von einer anderen .NET-Assembly stammt. Aber keine Hoffnung, wenn es von unmanaged Code kam.
Diese zufällige Art des Scheiterns ist einfach völliges Elend ohne einen vernünftigen Workaround. Dementsprechend wurde die Methode gekürzt. Die Verwendung von PCL ist eine mögliche Problemumgehung, aber Microsoft hat in der Vergangenheit streng davor gewarnt, dass eine solche Art von Hackorama sehr unrecommended ist. Bei einer Wahrscheinlichkeit ungleich Null wird dies von der Geschäftsvalidierungsprozedur abgefangen und führt zu einer Ablehnung.
Tags und Links .net reflection windows-runtime windows-store-apps portable-class-library