Ich verwende eine XML-Datei als eingebettete Ressource, um ein XDocument zu laden. Wir verwenden den folgenden Code, um die entsprechende Datei aus der Assembly zu erhalten:
%Vor% Wenn der Code bereitgestellt wird, werden wir gelegentlich auf die Seite gehen, und aus dem eingebetteten Dokument wird nichts geladen. Wenn wir das Ereignisprotokoll überprüfen, tritt kein Fehler auf. Wenn der Benutzer die Seite gerade aktualisiert, wird sie geladen. Das hat mich dazu gebracht zu glauben, dass assembly = Assembly.GetExecutingAssembly(); aus irgendeinem Grund gelegentlich null zurückgibt, und die Art, wie der Code geschrieben wird, ist kein Fehler. Also, meine Frage ist warum würde Assembly.GetExecutingAssembly(); Null zurückgeben? Ich habe ein paar Artikel darüber gefunden, dass es manchmal Fehler mit nicht verwaltetem Code gibt, aber diese Anwendung wird in C # geschrieben und über das Setup-Projekt bereitgestellt.
Der Code wurde ursprünglich ohne Fehlervermeidungscode geschrieben. Es wurde hinzugefügt, um zu verhindern, dass die Benutzer Fehleranzeigen erhalten. Die Ausnahmen werden in das Ereignisprotokoll des Servers geschrieben.
Dies ist ein perfektes Beispiel dafür, warum es fast immer eine schlechte Idee ist, Ausnahmen zu essen, besonders die oberste Ebene System.Exception . Das Problem könnte überall sein; wahrscheinlicher als nicht, ist das wahre Problem in Ihrem Logging-Code.
Entferne diese leeren catch Blöcke (oder wiederhole sie innerhalb von throw; ) und finde heraus, wo die Ausnahme wirklich auftritt. Und wenn Sie das eigentliche Problem gefunden haben und Ihren Code neu schreiben, schreiben Sie ihn um, um nur Ausnahmen zu erfassen, mit denen Sie eigentlich umgehen können .
GetExecutingAssembly gibt null , Punkt nicht zurück.
Sie sind mit dem falschen Paddel am Bach, GetExecutingAssembly () gibt niemals null zurück. Beweisen Sie es selbst, indem Sie den Fehlervermeidungscode entfernen, einschließlich des Null-Checks. Das gelegentliche Scheitern ist normalerweise ein Threading-Problem.
Wenn ich mit einer Situation wie dieser konfrontiert bin, versuche ich wirklich zu beweisen, dass der zurückgegebene Wert null war. Versuchen Sie Folgendes:
%Vor%Ich vermute, dass es immer "falsch" schreiben wird, und etwas anderes ist eigentlich das Problem - vielleicht etwas, das Sie nicht in Ihr Code-Snippet aufgenommen haben.
Dies kann null zurückgeben, wenn Sie Ihren Code von einer nicht verwalteten Anwendung (z. B. dem NUnit Test-Runner) starten: Versuchen Sie Folgendes mit der Konsole:
%Vor%Da Sie es eingebettet haben, nehme ich an, dass Sie eine Art Bootloader oder einen Interpreter verwenden, um Ihre .Net-App auszuführen. Das wäre wahrscheinlich nicht verwaltet (d. H. Nicht .Net interpretiert) und würde daher null zurückgeben.
Siehe Dokumentation, Abschnitt "Anmerkungen: Ссылка
Tags und Links c# assemblies system.reflection embedded-resource