GetEntryAssembly gibt null zurück ... wie kann man es vermeiden?

Ich habe eine WPF-Anwendung, die eine Bibliothek von Drittanbietern verwendet, um eine bestimmte Aufgabe auszuführen; Diese Bibliothek führt in einer ihrer Methoden die Anweisung Assembly.GetEntryAssembly() aus.GetEntryAssembly gibt null zurück ... wie kann man es vermeiden?

Wenn ich die WPF-Anwendung auf Debug ausführen (durch Ausführen einer .Net-Exe zum Testen) funktioniert die Bibliothek ordnungsgemäß und Assembly.GetEntryAssembly() gibt einen Verweis auf die Assembly der ausführbaren Datei, aber in der Produktion habe ich eine andere Situation, die mir einige verursacht Probleme.

In der Produktion ist die WPF-Anwendung in eine VB6-Anwendung integriert und Programme werden von einem VB6-Menü unter Verwendung der InteropFormLibrary gestartet; In diesem Fall löst die Bibliothek eine Ausnahme aus, da Assembly.GetEntryAssembly()null zurückgibt (die mit der Assembly verknüpfte ausführbare Datei kann nicht gefunden werden).

Mein Problem ist, dass ich den Code der Bibliothek nicht ändern kann, weil ich die Quellen nicht verfügbar habe und ich fand die Anweisung, die die Ausnahme durch dll Decompiler löst und die Methode analysiert, die in der Ausnahme war.

Jetzt ist meine Frage: Gibt es eine Möglichkeit, um sicherzustellen, dass die Methode nicht null zurückgibt? Kann ich etwas zuordnen oder "umgehen"?

Quelle

2012-04-13 Luca Petrini

Ist es möglich, die WPF-Anwendung innerhalb einer neuen AppDomain auszuführen? – Matten

Ich versuche, aber es gibt einige Probleme mit der Interop –

Der sauberste Weg ist, den Bibliotheksentwickler zu kontaktieren, da die MSDN die Tatsache angibt, dass 'GetEntryAssembly' 'null' zurückgibt, wenn sie aus nicht verwaltetem Code aufgerufen wird. http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getentryassembly%28v=vs.100%29.aspx – Matten

Der einfachste Weg wäre, den Entwickler der DLL dazu zu bringen, seinen Code so zu reparieren, dass er in einem nativen (wie VB6 oder C/C++) Prozess gehostet wird.

Wenn das nicht möglich ist, können Sie versuchen, Ihre .NET-Seite in einem separaten Prozess zu hosten, der auf einer .NET-Exe basiert. Da Sie VB6 Interop ausführen, werden Sie wahrscheinlich bereits COM-Interop verwenden, so dass Sie einfach auf das Out-of-Process-COM-Modell wechseln können. Auf diese Weise können Ihre .NET-Komponenten innerhalb einer .NET-Exe ausgeführt werden und haben eine Einstiegspunkt-Assembly. Ich habe das schon aus ähnlichen Gründen getan und es hat gut für mich funktioniert.

Quelle

2012-04-13 09:19:22 Zarat

Ja ... es scheint die einzige Lösung, jetzt versuche ich, die Bibliotheksentwickler zu kontaktieren, um das Problem zu beheben –

Eine andere "temporäre" und "gefährliche" Lösung, die ich gefunden habe, ist MSIL Disassembler (von Eingabeaufforderung mit ildasm Befehl) zu ändern Anweisung und dann neu kompilieren dll (mit ilasm-Befehl). Es funktioniert, aber es ist nicht die beste Wahl. –

Im Allgemeinen funktioniert es nicht so einfach, weil Sie den starken Namen der Assembly verlieren, was dazu führt, dass Sie jeden neu kompilieren, der auf diese Assembly verweist und möglicherweise eine große Kettenreaktion verursacht. – Zarat

GetEntryAssembly gibt null zurück ... wie kann man es vermeiden?

Antwort

Verwandte Themen