Dein Problem ist doch eigentlich ganz einfach. Wie schon gesagt muss in der Windows und Webanwendung ja auch ein Exception Handling eingebaut werden. Sprich es muss mit try catch gearbeitet werden. Sollte es in der Anwendung zu einem Fehler kommen, dann muss im catch Block deine Fehlerbehandlungsklasse mit einem zus�tzlichen Parameter aufgerufen werden. Zum Beispiel 1 f�r Webanwendung und 2 f�r Windowsanwendung.
Mit freundlichen Gr��en Andr� -----Urspr�ngliche Nachricht----- Von: Kristian Tingler [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 19. Oktober 2003 21:42 An: [EMAIL PROTECTED] Betreff: AW: [Asp.net] Web oder Windows Application? Hi! Super, danke! Das hilft mir jetzt auf jeden Fall weiter! Ich werd das gleich morgen frueh mal ausprobieren. Hatte ich auch noch extra vor, in der Global.asax einen Aufruf der statischen Fehlerbehandlungsroutinen hineinzuschreiben. Habt alle noch einen schoenen abend! Mit freundlichen Gruessen! Kristian Tingler bcs-Consult GmbH www.iss3.de -----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Joachim van de Bruck Gesendet: Sonntag, 19. Oktober 2003 20:31 An: [EMAIL PROTECTED] Betreff: AW: [Asp.net] Web oder Windows Application? Hallo! > Vielen Dank, fuer Deine eMail! Das ist genau das was mir vorschwebt. > Die eigentlichen Codes fuer einen Eintrag im EventLog, eMail versandt, > DialogBoxen sind bereits vorhanden. Dennoch vielen Dank, fuer Deine > Beispiele. Was mir jetzt noch fehlt, ist, wie kann ich aus einer > Exception-Instanz herausfinden, ob die Exception von einer Windows > oder einer Webapplication heraus aufgerufen wurde? Hm, da das Deine eigentliche Frage war, hatte ich das meines Erachtens direkt am Anfang beschrieben (HttpContext...). ;-) Ausprobieren musst Du das schon selber, also einfach mal Testen, was in Web.HttpContext.Current steckt, wenn man in einer WindowsForms-Application ist. Ich kann mir dann so etwas vorstellen: If(System.Web.HttpContext.Current==null) { // ich bin in WindowsForms } else { // ich bin in einer WebApp } Falls Du gar Dein ErrorHandling in eine eigenst�ndige Assembly steckst, kannst Du mit Assembly.CallingAssembly auf die aufrufende Assembly zugreifen. A B E R ... ... eine globale Klasse ErrorHandling halte ich ja nicht f�r sinnvoll, da diese wieder ein eigenes ExceptionHandling braucht, und eine separate Assembly schon gar nicht, da da ja Exceptions beim Laden ausgel�st werden k�nnen, die dann wieder behandelt werden m�ssen. Deshalb der ganze Sermon. ;-) Nimm so ein paar statische Routinen wie Exceptions.WriteToEventLog oder Exceptions.MailToDeveloper aus einer nicht inheritierbaren Klasse "Exceptions" und vergiss weitere Parameter und bringe das entscheidende Try-Catch-Finally direkt in "Sub Application_Error(...)" von Global.asax oder in die "Sub Main()". Freundliche Gr��e Joachim van de Bruck _______________________________________________ Asp.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/asp.net Virengepr�ft vom G DATA AntiVirenKit _______________________________________________ Asp.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/asp.net _______________________________________________ Asp.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/asp.net
