Warum sollte die Montage.GetExecutingAssembly() null zurück?

Ich bin mit einer xml-Datei als eingebettete Ressource laden ein XDocument. Wir verwenden den folgenden code, um die entsprechende Datei von der Baugruppe:

XDocument xd = new XDocument();
Assembly assembly = null;

try
{
    assembly = Assembly.GetExecutingAssembly();
}
catch(Exception ex)
{
    //Write exception to server event log
}

try
{
    if(assembly != null)
    {
        using(StreamReader sr = new 
            StreamReader(assembly.GetManifestResourceStream("assemblyPath")))
        {
            using(XmlTextReader xtr = new XmlTextReader(sr))
            {
                xd = XDocument.Load(xtr);
            }
        }
    }
}
catch(Exception ex)
{
    //Write exception to server event log
}

So, wenn der code bereitgestellt wird, werden wir gelegentlich auf die Seite zu gehen und es wird nichts geladen aus dem eingebetteten Dokument. Wenn wir überprüfen Sie das Ereignisprotokoll gibt es keine Fehler. Wenn der Benutzer gerade die Seite aktualisiert, es werden Last in Ordnung. Dies führt mich zu glauben, dass aus irgendeinem Grund, assembly = Assembly.GetExecutingAssembly(); ist vereinzelt null zurückgeben, und die Art, wie der code geschrieben ist, das ist nicht ein Fehler. So, meine Frage ist, warum sollte Assembly.GetExecutingAssembly(); werden null zurückgeben? Ich fand ein paar Artikel spricht über die Fehler manchmal mit nicht verwaltetem code, aber diese Anwendung ist in C# geschrieben und bereitgestellt über das setup-Projekt.

Den code ursprünglich geschrieben wurde, ohne Fehler-Vermeidung-code. Es wurde Hinzugefügt, um den Benutzer immer Fehler-Bildschirme. Die Ausnahmen werden in das Ereignisprotokoll des Servers.

Eine ganz dumme Frage (ich kann nicht imaging GetExecutingAssembly Versagen in der reinen managed code): tun, Fehler passieren in jedem anderen Stück code), die zu einem Eintrag in das Ereignisprotokoll geschrieben ? Ich Frage nur um sicher zu sein, dass das Ereignisprotokoll schreiben von code korrekt ist und dass Ausnahmen ausgeschlossen werden kann.
Sorry, sollte angegeben haben, die es ein bisschen mehr. Die Fänge sind den Aufruf einer Methode in einer utility-Projekt zu schreiben, die Ausnahme von der event-log. Der code, dies zu tun ist in der gesamten Anwendung verwendet, und funktioniert. Auch der obige code ist eine Methode, die aufgerufen wird, während die Seite Initialisierung.
So, nachdem ich, dass jeder scheint zu vereinbaren, dass GetExecutingAssembly() nicht null zurückgeben, ich ging zurück und schaute auf den rest der Methode. Nach einigem suchen fand ich diesen Artikel auf der MSDN-Website: msdn.microsoft.com/en-us/library/xc4235zt(VS.85).aspx. In es ist, sagt GetManifestResourceStream() kann null zurückgeben, wenn die Ressource nicht gefunden werden oder unzugänglich sind. Null zurückgeben, um der using () - Konstrukt nicht dazu führen würde, eine Ausnahme. Also gehen wir zur Bereitstellung dieser und sehen, ob es der Schuldige ist.
Ich hoffe, dass durch die "deploy" - du meinst "die Bereitstellung einer test-version auf einem test-Rechner mit einem test-server", und dass Sie nicht in der Tat die Produktion schiebt für die "smoke-tests", wie der Letzte Kommentar scheint zu implizieren. Nächste mal, wenn Ihr Benutzer beginnen immer Ausnahmen, ich empfehle beheben des Fehlers, der verursacht, anstatt nur die Unterdrückung der Benachrichtigung.
Durch den "deploy" - ich meine, es wird gehen, über ein anderes QS-Zyklus. So weit das Problem wurde bisher nur gesehen in der Produktion code, obwohl, so dass ich bezweifle, dass wird sich jetzt ändern. Wie bei der Behebung der Fehler, dass ist es, was ich versuche zu tun, jetzt.
"es wurde Hinzugefügt, um zu verhindern, dass Benutzer immer Fehler-screens" - was meinst du? Sie können nicht ändern die app/web.config so dass die Nutzer nicht sehen, Fehler wie diesen hier? War es überhaupt eine Auflösung?

InformationsquelleAutor Nathan | 2010-03-04

assemblies c#embedded-resource system.reflection

7

Dies ist ein perfektes Beispiel dafür, warum es eine fast durchgängig schlechte Idee, zu Essen, Ausnahmen, insbesondere der top-level -System.Exception. Das problem könnte überall sein; wahrscheinlicher als nicht, das eigentliche problem ist Ihre logging-code.

Nehmen Sie diese leeren catch Blöcke (oder rethrow in Ihnen mit throw;) und sehen, wo die Ausnahme ist wirklich Auftritt. Und wenn man einmal das eigentliche problem und schreiben Sie Ihren code umzuschreiben, Sie zu fangen, nur Ausnahmen, die Sie eigentlich wissen, wie zu behandeln.

GetExecutingAssembly wird nicht zurück null Zeit.

InformationsquelleAutor Aaronaught
5

gehen Sie zu den Eigenschaften der Datei, deren Pfad erwähnt wird, und ändern der buildAction-aus dem Inhalt was ist die Standard-Einstellung zu EmbeddedResource. Neu kompilieren und dann sollte es klappen.

InformationsquelleAutor Sap
3

Sind Sie bis auf den Bach mit dem falschen Paddel, GetExecutingAssembly() nie null zurück. Beweis es zu sich selbst, indem Sie alle Fehler-Vermeidung-code, einschließlich der null-check. Erste gelegentliche Ausfall ist in der Regel ein threading-Problem.

InformationsquelleAutor Hans Passant
2

Dies könnte einer der Gründe - http://winterdom.com/2003/04/assemblygetexecutingassembly

InformationsquelleAutor codemonkey
2

Kann null zurückgeben, wenn Sie das starten von code aus einer nicht verwalteten Anwendung (z.B. NUnit-Test-runner): Versuchen Sie Folgendes über die Konsole:
```
[Test]
public void att()
{
    Assert.NotNull(Assembly.GetExecutingAssembly());
}
```
Sehen, wie Sie markiert haben es embedded, ich nehme an, du verwendest eine Art bootloader oder interpreter zur Ausführung Ihres .Netto-app? Das wäre wahrscheinlich nicht verwalteten (D. H. nicht .Net interpretted) und daher würde null zurückgeben.

Finden Sie in der Dokumentation, im Abschnitt "Bemerkungen: http://msdn.microsoft.com/en-us/library/system.reflection.assembly.getentryassembly.aspx
- Nicht, dass jemand geht, um es zu betrachten jetzt :/
InformationsquelleAutor chrisb
1

Wenn Sie mit einer situation wie dieser versuche ich, um wirklich zu beweisen, dass der zurückgegebene Wert null war. Versuchen Sie dies:
```
try
{
    assembly = Assembly.GetExecutingAssembly();
    Log.Write("Executing assembly is null: " + (assembly == null))
}
catch(Exception ex)
{
    //Write exception to server event log
}
```
Ich vermute, es wird immer schreiben, "false", und etwas anderes ist eigentlich das problem - vielleicht etwas, was Sie nicht in Ihrem code-snippet.

InformationsquelleAutor Roman Starkov

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.