Gethrforexception

Ich habe einige IO-Code, der einen Stream innerhalb eines try..catch liest. Es fängt IOException und ruft System. Runtime. InteropServices. Marshal. GetHRForException () innerhalb der catch, in einem Versuch, verschiedene Aktionen auf der Grundlage der HResult nehmen. So etwas wie dieses: Aber diesen Code in ASP. NET mit trustmedium ausführen, bekomme ich diese Ausnahme: Ein paar Fragen: Ich denke, die Ausnahme ist aufgetreten, weil GetHRForException ruft in nicht verwalteten Code, der nicht in Medium Vertrauen erlaubt ist. Korrigieren Diese Ausnahme wird geworfen, nicht zum Zeitpunkt der Ausführung von GetHRForException, aber zum Zeitpunkt der Methode wird JITed - Correct (Der stacktrace zeigt meine Methode, aber ich bin 99 sicher, dass eine IO-Exception nicht aufgetreten ist) Wenn ja, Gibt es eine Möglichkeit für mich, das Verhalten in einer partiellen Vertrauensumgebung variieren, so dass ich nicht rufen Sie die GetHRForException (nicht verwalteten Code), wo es nicht erlaubt ist Mit anderen Worten, wie kann ich dem JIT erlauben, zum Zeitpunkt der Kompilierung erfolgreich zu sein, während auch Auswertung zur Laufzeit, ob der Code GetHRForException aufrufen sollte () So etwas wie dies: Ich denke, es gibt einen Laufzeitmechanismus für den Test, wenn Berechtigungen verfügbar sind, aber havent in der Lage, es zu finden. BEARBEITEN. Ist dieser Blog-Artikel die Antwort ShawnFa von Microsoft sagt, dass Sie nicht versuchen können. Catch (SecurityException) um eine Methode, die durch einen LinkDemand geschützt ist. Wenn MethodA () MethodB () aufruft und MethodB () mit LinkDemand für vollständige Vertrauenswürdigkeit markiert wird, wird der LinkDemand überprüft, wobei MethodA Jited ist. Deshalb, um die SecurityException zu vermeiden, muss ich Marshal. GetHRForException in eine separate Methode extrahieren. Ist das korrekt Auf meinen Code angewendet, kann MethodA () der Code sein, der Read aufruft und dann im catch versucht, GetHRForException () aufzurufen. GetHRForException ist MethodB (). Der LinkDemand wird ausgewertet, wenn MethodA () JITd ist. (Dieser LinkDemand schlägt in meinem Medium vertrauen ASP. NET-Szenario). Wenn ich die GetHRForException in eine neue Methode MethodC () verschieben und MethodC () nur bedingt aufrufen, nachdem eine imperative permission. Demand () erfolgreich ist, sollte ich theoretisch die SecurityException an der JIT-Zeit vermeiden können, da MethodC () sein wird JITd nur, nachdem die permission. Demain () erfolgreich ist. Gestellt Jul 12 09 am 14:20 Die erforderliche Methode ist SecurityPermission. IsUnrestricted (). Es gibt eine true oder false, die angibt, ob die Berechtigung erlaubt ist oder nicht. Es erfordert keine Berechtigung, ebenso wie SecurityPermission. Demand (). Ich benutze IsUnresticted mit SecurityPermissionFlag. UnmanagedCode zu sehen, wenn die Assembly darf nicht verwalteten Code aufrufen, und rufen Sie den nicht verwalteten Code nur, wenn erlaubt. Es gibt einen zusätzlichen Twist. Der JIT-Compiler prüft beim Kompilieren einer Methode nach CodeAccessPermission LinkDemands auf jede Methode, die als die zu kompilierende Methode bezeichnet wird. Marshal. GetHRForException () ist mit einem LinkDemand markiert. Daher wird meine Methode, die Marshal. GetHRForException () aufruft, eine uncatchable SecurityException zum Zeitpunkt der JIT-Kompilierung werfen, wenn in einer beschränkten Umgebung wie ASP. NET mit mittlerer Vertrauenswürdigkeit ausgeführt wird. Daher muss man nicht JIT die Methode, die Marshal. GetHRForException () in diesem Fall, was bedeutet, dass ich ausbrechen müssen, Marshal. GetHRForException () in eine separate Methode in meinem Code, der aufgerufen wird (und somit JITted) nur dann, wenn UnmanagedCode ist uneingeschränkt. Heres einige Beispiel-Code: beantwortet Jul 20 09 at 17:56 Ja - mittlere Vertrauen wird nicht zulassen, Anrufe in nicht verwalteten Code. Die einzige Vertrauensstufe, die es zulässt, ist volles Vertrauen. Es hängt davon ab, ob. CAS-Anforderungen können zur Laufzeit stattfinden, aber die Hosting-Umgebung kann auch auf eine Wanderung gehen und suchen Dinge, die sie nicht tun kann. Sie können testen, um festzustellen, ob Sie einen nicht verwalteten Code anrufen können, indem Sie eine CAS-Anfrage mit einer Instanz von SecurityPermission verwenden. Der Code, um eine CAS-Nachfrage sieht aus wie dies beantwortet. Dies deckt Teil b von Q3 ab. Aber was ist mit Teil a wie bekomme ich die JIT-Kompilierung zum Erfolg Kann ich meine Methode mit einem Sicherheitsattribut oder markieren. Denken Sie daran, meine Theorie ist, dass der SecurityPermission-Fehler nicht zur Laufzeit geschieht, es geschieht während JIT - und ich denke, Sie bestätigt, dass dies möglich ist. Also die Frage ist, wie schreibe ich den Code, damit die JIT zu kompilieren. Ndash Cheeso Es sollte zur Laufzeit geschehen, sonst würde die Montage wouldn39t sogar laden - und dafür muss die Assembly muss als die Erlaubnis erforderlich markiert werden. Selbst dann that39s wohl ein Laufzeit-Check, wie es bei Montage Belastung, die zur Laufzeit sein könnte passieren wird. Ndash blowdart Unterschiedliche Art der Überprüfung, Link-Anforderungen sind Attribute auf eine Methode, und werden tatsächlich bei JIT-Zeit überprüft. It39s ziemlich viel vom Rahmen selbst verwendet und es ist selten, es außerhalb der CLR-Quelle zu sehen. Was ich demonstrieren ist eine zwingende Forderung, nicht eine deklarative wie eine SecurityPermission (SecurityAction. LinkDemand, uneingeschränkte true) ndash bladdart am 12. Juli um 18: 55Marshal. GetHRForException hat mehr als nur Get-HR-For-Exception Let8217s ersten Start durch suchen Bei einem kleinen Code-Snippet: Das sieht ganz gut aus, nicht wirklich. Es stellt sich heraus, diese API ist eigentlich schlecht benannt, und es tatsächlich mehr als nur Abrufen der HR aus dem Ausnahmeobjekt. Mit dieser API falsch können Sie einige seltsame Probleme, wie das Auswerfen einer falschen, alten Ausnahme. Also, was bedeutet die API tatsächlich tun Neben der Rückgabe Sie die HRESULT, diese Funktion setzt auch das aktuelle Thread IErrorInfo-Objekt das Ausnahmeobjekt sein. Jeder Thread hat ein assoziertes IErrorInfo COM-Objekt, standardmäßig auf NULL. Dieses IErrorInfo-Objekt stellt den Fehler des letzten COM-API-Aufrufs dar, der wie die GetLastError () - Win32-API oder errno-C-API ist. Von dem IErrorInfo-Objekt können Sie weitere Informationen wie die Fehlerbeschreibung, Hilfedatei Kontext, etc, erhalten, die Ihnen weitere Informationen über den Fehler. Durch das Setzen des IErrorInfo-Objekts auf das Ausnahmeobjekt (tatsächliche Einstellung auf die IErrorInfo-Implementierung des Ausnahmeobjekts, das von allen verwalteten Objekten gemeinsam genutzt wird), erzählen Sie im Wesentlichen Ihren COM-Aufrufern, quothey, gibt es einen Fehler, it8217s dieses Ausnahmeobjekt und Sollten Sie etwas über itquot tun, was offensichtlich eine schlechte Idee ist, wenn Sie nur den HR abrufen möchten. In vielen Fällen könnte dies unbemerkt gehen, wenn Ihr COM callercallee IErrorInfo korrekt behandelt. Ich denke, sie folgen dem COM IErrorInfo-Protokoll, das sind im Grunde: 1. Der Anrufer verwenden IErrorInfo aus dem aktuellen Thread beim Aufruf einer COM-Schnittstelle, die explizit sagt, dass ich IErrorInfoquot 2. Die callee (die die COM-Schnittstelle implementiert), die besagt QuotI Support IErrorInfoquot, muss IErrorInfo vor der Rückgabe löschen. Dies ist sehr ähnlich zu GetLastError () errno, rechts Wenn dies der Fall ist, wird die falsch eingestellte IErrorInfo in den Thread typischerweise entweder überschrieben durch einige Interface-Implementierung, die IErrorInfo unterstützt oder ignoriert. Jedoch, weil das Protokoll, das ich beschrieben wurde, von jedem COM-Entwickler wirklich nicht sehr gut verstanden wird, I8217ve häufig gesehen Fälle, in denen die COM-Komponente gerade quotsure sagt, stütze ich IErrorInfo auf jedem COM interfacequot und sie don8217t setclear IErrorInfo überhaupt. Und dann, der Anrufer dieser schlecht implizierten COM-Schnittstelle, würde am Ende mit dem IErrorInfo durch GetHRForException Aufruf früher gesetzt und ist zu glauben, dass es einen Fehler. Beispielsweise berücksichtigen let8217s das folgende Szenario: Einige COM-Komponente A Aufrufe in. NET-Code. NET-Code werfen eine Ausnahme, sagen IOException. NET-Code fängt die Ausnahme, und rufen Sie Marshal. GetHRForException, die IErrorInfo auf diese Ausnahme IOException. NET-Code setzt Anrufe in eine andere COM-Komponente B, Aufrufe in IB. Func IB. Func fehlgeschlagen und einige HR Fehlercode zurückgeben, sagen EOUTOFMEMORY CLR sieht den HR-Fehlercode und fragen Sie die COM-Komponente B quotdo Sie unterstützen IErrorInfoquot, und B antwortet quotsure, warum notquot , Außer es doesn8217t wirklich unterstützen und es doesn8217t setclear IErrorInfo CLR abrufen die IErrorInfo, und sieht, dass es tatsächlich eine verwaltete Ausnahme und wirft die IOException Ausnahme statt OutOfMemoryException. Jetzt können Sie sich fragen: Was ist diese API wirklich für den ersten Platz gedacht Es ist tatsächlich in Orten in COM verwendet interop, wo Sie die HRESULT zurückgeben und setzen Sie IErrorInfo von Ihnen. Diese doesn8217t passieren sehr oft 8211 die meisten Menschen wäre glücklich genug, um COM-Interop kümmert sich um dieses Teil durch die Umwandlung von Exception in HR und IErrorInfo (was geschieht, um Marshal. GetHRForException aufrufen). So, wenn Sie nicht wirklich wissen, was Sie tun, ist mein Rat, weg von Marshal. GetHRForException zu bleiben. Was passiert, wenn Sie wirklich wollen, nur die HRESULT für eine bestimmte Ausnahme erhalten Sie sollten Exception. HResult Eigenschaft verwenden.