Real-World SharePoint Entwicklung: Logging und Fehlerbehandlung in SharePoint 2010– Teil 1

Von Andreas Aschauer Autor Feed 21. January 2011 14:30

Als SharePoint Entwickler ist man es gewohnt umfangreiche Trace Logs und und das Windows Event Log durchzukämmen. Besonders die Informationen welche von SharePoint in die Trace Log Dateien im 14-Hive unter \LOGS, sind extrem umfangreich, je nach den Einstellungen in der Farm.

Auf dem eigenen virtuellen Entwicklungsserver mag das durcharbeiten der Log Dateien noch erträglich sein – besonders mit nützlichen Tools wie dem ULS Log Viewer. Wird die eigene Solution dann auf ein Test/Staging System ausgerollt und das Testen geht so richtig los, hört der Spass dann meist auf. Die Logs jedes mal via RDP öffnen oder irgendwie kopieren und durchkramen ist mühsame Arbeit.

In diesem un den folgenden Posts wollen wir uns mehrere Dinge ansehen welche uns das Logging Leben erleichtern sollen in SharePoint 2010.

- Eigene Informationen via ULS in die Trace Logs schreiben
- Die Trave Logs effizient verwalten und einfach durchsuchen

Eigene Informationen via ULS loggen

Das Einbringen von eigenen Logging Informationen ist eigentlich erfrischend einfach – man glaubt es kaum, aber in den Weiten des Internets kursieren viele Beispiele, welche Unmanaged Code und die Windows API dazu verwenden.

Im folgenden ein klassisches “Hello World” Beispiel, wie mit der SharePoint API direkt in SharePoint Server Trace Logs geschrieben werden kann.

Logging “Hello World” Beispiel

Zuerst ist eine Referenz auf die Assembly Microsoft.Office.Server erforderlich

image

Diese Assembly ist teil von SharePoint SERVER – also auf Systemen, welchen lediglich die Gratis “SharePoint Foundation” besitzen nicht verfügbar.

Über die statische Klasse PortalLog im Namespace Microsoft.Office.Server.Diagnostics wird direkt ins Trace Log geschrieben.

   1: void LogMessage(string message)
   2: {
   3:     Microsoft.Office.Server.Diagnostics.PortalLog.LogString(message);
   4: }

Einfacher gehts kaum!

Interessant ist bei SharePoint basierten Solutions oft auch, welche Methode aufgerufen wurde im Custom Code – zum Beispiel wenn Event Receiver zum Einsatz kommen. Den Aufruf und das Verlassen einer Methode logged man wie in Beispiel 2.

   1: void LogMessage(string message)
   2: {
   3:     Microsoft.Office.Server.Diagnostics.PortalLog.EnterFunction("SPLoggingSample.WebParts.LogMessage");
   4:     Microsoft.Office.Server.Diagnostics.PortalLog.LogString(message);
   5:     Microsoft.Office.Server.Diagnostics.PortalLog.LeaveFunction("SPLoggingSample.WebParts.LogMessage");
   6: }

Will man das Loggin in einem try..catch Block verwenden, sollte man immer darauf achten, nach dem entsprechenden Loging Code eine Instanz von SPException zu werfen, damit SharePoint auf den Fehler mit einer Fehlerseite für den User reagieren kann.

   1:  
   2: void DoSomething()
   3: {
   4:     try
   5:     {
   6:  
   7:     }
   8:     catch (Exception ex)
   9:     {
  10:         LogMessage("Error in DoSomething()" + ex.Message);
  11:         throw new SPException(@"Ein Fehler ist aufgetreten. Die Fehlerinformationen wurden protokolliert. 
  12:             Kontaktieren sie ihren Administrator");
  13:     }
  14: }

SharePoint reagiert automatisch auf eine SPException mit der bekannten weissen Fehlerseite.

image

Das Austauschen von eingabauten SharePoint Application Pages, wie der “Access Denied” Seite oder eben der obigen Fehlerseite, war bisher nur möglich in dem die entsprechenden ASPX Seiten im _layouts Ordner verändert wurden. Mit SharePoint 2010 gibt es die Möglichkeit Systemseiten im Code zu verändern, am besten beim Aktivieren des entsprechenden Features.

   1: public override void FeatureActivated(SPFeatureReceiverProperties properties)
   2:        {
   3:            var webApp = properties.Feature.Parent as SPWebApplication;
   4:            if (webApp != null)
   5:            {
   6:                // Set Access Denied.
   7:                if (!webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.AccessDenied,
   8:                    "/_layouts/CodeForceErrorPages/AccessDenied.aspx"))
   9:                {
  10:                    throw new ApplicationException("Failed setting new access denied page mapping.");
  11:                }
  12:  
  13:                // Set Signout.
  14:                if (!webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.Signout,
  15:                    "/_layouts/CodeForceErrorPages/Signout.aspx"))
  16:                {
  17:                    throw new ApplicationException("Failed setting new signout page mapping.");
  18:                }
  19:  
  20:                // Set File Not Found.
  21:                webApp.FileNotFoundPage = "/_layouts/CodeForceErrorPages/FileNotFound.htm";
  22:  
  23:                webApp.Update(true);
  24:            }
  25:        }

Das Schöne hierbei ist, dass sich die Änderungen nur auf eine Anwendung beziehen!

Soweit das einfachste Logging Szenario – hilft aber bei Problemen welche in Custom Code stecken schon sehr gut weiter um Fehler nachzuvollziehen.

Im nächsten Artikel sehen wir uns die neuen Dienste welche SharePoint 2010 zum Thema Logging bietet genauer an. Danach soll ein WebPart – ein LogViewer – erstellt werden, der uns direkt in der Weboberfläche ein Betrachten und Filtern der Logeinträge ermöglicht. In Teil 3 zu guter Letzt gehe ich dann noch auf selbst entwickelte Logging Provider ein, die es zB ermöglichen Fehlermeldungen via WebService zu versenden.

Stay tuned for more Up-Front SharePoint Development!

ShakeHands_thumb1_thumb_thumb

Andreas Aschauer

Comments (2) -

>

3/27/2011 8:51:35 PM #

Hallo,
toller Blogeintrag. Er hat nur einen gravierenden Fehler und zwar die Verwendung der statischen Klasse "PortalLog". Die Verwendung wird und darf ausschließlich von Microsoft verwendet werden. In der Klassenbeschreibung von msdn.microsoft.com/.../...agnostics.portallog.aspx ist klar vermerkt:
"This class and its members are reserved for internal use and are not intended to be used in YOUR code."
Dem kann aber einfach Abhilfe geschaffen werden, da in den "Micorsoft Pattern & Practices" dem Logging aus SharePoint ein ganzes Kapitel gewidmet ist.
Ein Dokument das jeder SharePoint Entwickler kennen sollte.

lg
Stefan Bauer
Microsoft Community Contributor Award 2011

Stefan Bauer Vereinigte Staaten

>

4/20/2011 3:07:02 PM #

Hallo!

Zu den Patterns & Practices Logging Themen, gibt es auf codefest.at von mir noch weitere Artikel. Obiges Beispiel ist die Quick & Dirty Implementierung, da für kleinere Projekte die Arbeit mit den Lösungen aus P&P oft zu viel Zeit in Anspruch nimmt und meiner Erfahrung nach sind die Komponenten wie der Service Locator und der darauf aufbauende Logger noch nicht ganz fehlerfrei.

Ausserdem, die verwendung einer Klasse kann man doch niemandem verbieten, der sie als Teil seiner SharePoint Lizenz "mitkauft" - das wären ja fast APPLE Methoden ;)


lg


Andreas Aschauer Österreich

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading

Datenschutzhinweis: Sie stimmen durch "Kommentar speichern" der Speicherung Ihrer Angaben durch Microsoft Österreich für die Beantwortung der Anfrage zu. Sie erhalten dadurch keine unerwünschten Werbezusendungen. Ihre Emailadresse wird auf Ihren Wunsch dazu verwendet Sie über neue Kommentare zu informieren.

Microsoft respektiert den Datenschutz. Datenschutz & Cookies

Entwickler Wettbewerbe:

Wettbewerbe

Entwickler Events:

Developer Events

App für Windows 8, Windows Phone oder/und Azure? Diese Events zeigen Dir, wie es geht:

Mehr Information

Aktuelle Downloads

Visual Studio Downloads
 
Windows Azure Free Trial
Instagram
CodeFest.at on Facebook

Datenschutz & Cookies · Nutzungsbedingungen · Impressum · Markenzeichen
© 2013 Microsoft. Alle Rechte vorbehalten · BlogEngine.NET 2.7.0.0 · Diese Website wird für Microsoft von atwork gehostet.
powered by atwork