Funktionen für das Debuggen und die Protokollierung in SharePoint 2010

Zusammenfassung: Dieser Artikel bietet Informationen über die neuen Protokollierungs- und Debuggingfunktionen in SharePoint Foundation 2010, mit denen Entwickler zuverlässigere und besser testbare Lösungen erstellen können.

Letzte Änderung: Mittwoch, 12. Januar 2011

Gilt für: Business Connectivity Services | Office 2010 | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Inhalt dieses Artikels
Einführung in das Debuggen und die Protokollierung in SharePoint 2010
Protokollierung in SharePoint 2010
Fehlerberichterstattung in SharePoint 2010
Benutzerdefinierte SharePoint-Anwendungsseiten
Entwicklerdashboard in SharePoint 2010
Schlussbemerkung
Weitere Ressourcen

Inhalt

• Einführung in das Debuggen und die Protokollierung in SharePoint 2010

• Protokollierung in SharePoint 2010

• Fehlerberichterstattung in SharePoint 2010

• Benutzerdefinierte SharePoint-Anwendungsseiten

• Entwicklerdashboard in SharePoint 2010

• Schlussbemerkung

• Weitere Ressourcen

   Code zum Herunterladen

Einführung in das Debuggen und die Protokollierung in SharePoint 2010

Microsoft SharePoint 2010 ist ein umfassend erweiterbares Produkt, das Entwickler auf die unterschiedlichsten Geschäftsanforderungen zuschneiden können. Da SharePoint auf Microsoft ASP.NET basiert, bietet es Entwicklern die gleichen Optionen für Debuggen und Protokollierung, die auch auf herkömmlichen ASP.NET-Websites zur Verfügung stehen. Zusätzlich zu den Optionen von ASP.NET bietet SharePoint 2010 weitere Optionen in den Bereichen Debuggen und Protokollierung, die Entwickler bei der Überwachung von Anwendungen und der Problembehandlung unterstützen.

In diesem Artikel werden verschiedene Aspekte des Debuggens und der Protokollierung angesprochen und Techniken erklärt, die Entwickler in ihren benutzerdefinierten SharePoint 2010-Anwendungen einsetzen können.

Neues in SharePoint 2010 für die Protokollierung und das Debuggen

Die besten Anwendungen enthalten ein Paket von Protokollierungsfunktionen, die Entwicklern beim Auffinden und Analysieren von Fehlern helfen, wenn die Anwendung nicht wie vorgesehen funktioniert oder unerwartete Probleme auftreten. Microsoft Office SharePoint Server 2007 bietet Entwicklern alle Tools, die auch in ASP.NET verfügbar waren, z. B. das Debugging- und Ablaufverfolgungsprotokoll. Entwickler können auch in das SharePoint-Protokoll (auch Vereinheitlichter Protokollierungsdienst [Unified Logging Service, ULS] genannt) schreiben, allerdings bringt das Schreiben direkt in die Protokolldateien zusätzliche Arbeit mit sich.

Microsoft hat SharePoint 2010 mit zusätzlichen Funktionen für das Debuggen und die Protokollierung ergänzt, damit Entwickler die Möglichkeit haben, weitere Überwachungs- und Problembehandlungsfunktionen in ihre benutzerdefinierten Anwendungen zu integrieren. In diesem Artikel werden die folgenden neuen Bereiche in SharePoint 2010 beschrieben:

• Korrelationstokens

• Protokollierungsdatenbank

• Benutzerdefinierte Fehlerseiten

• Entwicklerdashboard

Protokollierung in SharePoint 2010

Jeder Server, auf dem Windows SharePoint Services 3.0 und Office SharePoint Server 2007 ausgeführt wurden, schrieb Protokollierungsinformationen in die ULS-Protokolldateien und das Serverereignisprotokoll. Die ULS-Protokolldateien im Ordner {SharePoint Root}\LOGS auf jedem Farmserver mit SharePoint konnten eine ganze Menge von Informationen enthalten, je nachdem, wie die Diagnoseprotokolleinschränkung konfiguriert war. Zwar möchten die meisten Entwickler lieber mehr Einzelheiten in den Protokolldateien haben als weniger, doch kann die schiere Menge an Details das Auffinden eines bestimmten Eintrags in den Protokolldateien erschweren. SharePoint 2010 erleichtert das Auffinden von einzelnen Protokolleinträgen, indem jedem Protokolleintrag eine bestimmte Eindeutigkeit zugewiesen wird. Diese Eindeutigkeit wird als Korrelationstoken bezeichnet und ist eine GUID (Globally Unique Identifier), die dem Benutzer angezeigt wird, wenn ein Fehler auftritt. Ein Administrator oder Entwickler kann diese GUID-Zeichenfolge aus der Fehlermeldung für die Suche nach einem bestimmten Eintrag in der Protokolldatei verwenden. Anhand des Korrelationstoken kann er Protokolleinträge rasch finden, um Fehler zurückzuverfolgen.

Im ULS kann außerdem anhand von bestimmten Kriterien konfiguriert werden, wie viele Einzelheiten in den Protokolldateien und im Ereignisprotokoll aufgeführt werden. Im Artikel Konfigurieren der Diagnoseprotokollierung (SharePoint Foundation 2010) im Microsoft TechNet wird veranschaulicht, wie die Diagnoseprotokollierung in SharePoint 2010 konfiguriert wird.

SharePoint-Protokollierungsdatenbank

Eine weitere Neuerung von Microsoft ist eine neue Datenbank, die alle Protokollierungsinformationen für alle Server in der Farm enthält. Die Erstellung dieser Datenbank basiert auf einigen neuen Zeitgeberaufträgen. Nachdem Sie diese Aufträge aktiviert haben (standardmäßig sind sie alle deaktiviert), werden von SharePoint Diagnoseprotokollierungsdaten in eine neue Microsoft SQL Server-Datenbank eingefügt. Die neuen Zeitgeberaufträge sind folgende:

• Diagnosedatenanbieter: Ereignisprotokoll

• Diagnosedatenanbieter: Leistungsindikatoren - Datenbankserver

• Diagnosedatenanbieter: Leistungsindikatoren - Web-Front-Ends

• Diagnosedatenanbieter: SQL-Sperrabfragen

• Diagnosedatenanbieter: SQL-DMV

• Diagnosedatenanbieter: DMV-Daten des SQL-Speichers

• Diagnosedatenanbieter: Ablaufverfolgungsprotokoll

Diese Zeitgeberaufträge sind in der Referenz für Zeitgeberaufträge (SharePoint Server 2010) ausführlich dokumentiert. Einer der Hauptvorteile der Aktivierung dieser Aufträge besteht darin, dass all die verschiedenen Protokolle in einer einzigen, zentralen Datenbank zusammengeführt werden, in der aus verschiedenen Quellen Abfragen ausgeführt werden können. Der Inhalt dieser Protokollierungsdatenbank könnte sogar mithilfe von externen Microsoft Business Connectivity Services (BCS)-Inhaltstypen und externen Listen verfügbar gemacht werden.

Lesen der SharePoint-ULS-Protokolle

Neben der neuen Protokollierungsdatenbank in SharePoint 2010 können Entwickler auch die SharePoint-Rohprotokolldateien analysieren, die im Ordner {SharePoint Root}\LOGS auf jedem Server erstellt werden. Beim Erstellen von Lösungen arbeiten Entwickler typischerweise in einer isolierten Umgebung, in der alles auf einem einzigen Server installiert ist und nicht in einer Farm, die aus mehreren Servern besteht. Die Protokolldateien sind im Grunde genommen große Textdateien mit fester Breite mit Trennzeichen, die mit einem beliebigen Text-Editor gelesen und durchsucht werden können.

Neben dem Durchsuchen von Rohtextdateien bietet sich noch die Möglichkeit, verschiedene Hilfsprogramme zum Lesen der SharePoint-Protokolldateien zu nutzen, die von einer Reihe von Entwicklern veröffentlicht wurden. Eine Schnellsuche nach SharePoint ULS Viewer liefert zahlreiche Ressourcen hierzu. Einige dieser Hilfsprogramme bieten Benachrichtigungen und Verfahren, die das Suchen und Filtern nach bestimmten Kriterien gegenüber der Verwendung eines Standard-Text-Editors enorm vereinfachen.

Schreiben in die SharePoint-ULS-Protokolle

Das Lesen von SharePoint-ULS-Protokollen erweist sich bei der Problembehandlung für in SharePoint generierte Fehlermeldungen als sehr hilfreich. Was Entwickler aber wirklich brauchen, ist die Möglichkeit eigene Meldungen in die Protokolldateien zu schreiben. Das Schreiben in die Protokolldateien in SharePoint 2010 hat Microsoft nun durch die Verwendung der SPDiagnosticsService-Klasse erheblich vereinfacht, wie im folgenden Beispiel veranschaulicht.

try{
  ...
} catch (Exception ex) {
  SPDiagnosticsService.Local.WriteTrace(0, new SPDiagnosticsCategory("MSDN", TraceSeverity.Unexpected, EventSeverity.Error), TraceSeverity.Unexpected, ex.Message, ex.StackTrace);
}

Mit dem obigen Codeausschnitt werden die Einzelheiten der Ausnahme in das SharePoint-ULS-Protokoll geschrieben. Bei der näheren Untersuchung des Eintrags, der hinzugefügt wird, wird der Entwickler feststellen, dass der Eintrag für die Spalte Product hier Unknown lautet. Dies ist das Standardverhalten der SPDiagnosticsService-Klasse. Zum Hinzufügen von benutzerdefinierten Produktnamen kann der Entwickler einen eigenen Diagnosedienst implementieren, indem er die SPDiagnosticsServiceBase-Klasse verwendet. Leider ist die Interaktion mit einem benutzerdefinierten SPDiagnosticsService nur in voll vertrauenswürdigen Farmlösungen möglich und nicht in Lösungen mit eingeschränkter Sicherheitsstufe. Wenn das Schreiben in die ULS-Protokolle mit der SPDiagnosticsService-Klasse aus dem Sandkasten ermöglicht werden soll, kann der Entwickler einen voll vertrauenswürdigen Proxy erstellen, in dem von Lösungen mit eingeschränkter Sicherheitsstufe Aufrufe ausgeführt werden können. In den nächsten beiden Abschnitten wird erklärt, wie in die SharePoint-ULS-Protokolle geschrieben werden kann.

Microsoft hat also die Möglichkeit geschaffen, eine benutzerdefinierte SPDiagnosticsService-Klasse zu schreiben. Darüber hinaus hat die Microsoft-Gruppe Patterns & Practices den Leitfaden Entwickeln von Anwendungen für SharePoint 2010 veröffentlicht, der eine SharePoint-Protokollierung enthält. Der Entwickler sollte beim Erstellen von benutzerdefinierten Anwendungen alle diese Vorgehensweisen in Betracht ziehen.

Erstellen eines benutzerdefinierten Protokollierungsdiensts

Wenn Sie einen benutzerdefinierten Protokollierungsdienst in einer benutzerdefinierten Anwendung erstellen möchten, müssen Sie eine neue Implementierung der SPDiagnosticsServiceBase-Klasse erstellen, eine einzige Methode überschreiben und mehrere Möglichkeiten zum Schreiben in die Protokolldateien bereitstellen.

Im folgenden Beispiel wird gezeigt, wie Sie einer anderen Anwendung als einer Lösung mit eingeschränkter Sicherheitsstufe eine neue Klasse hinzufügen und festlegen, dass diese Klasse von der SPDiagnosticsServiceBase-Klasse erbt.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.Administration;

namespace MSDN.SharePoint.Samples.WriteToUls {
  public class LoggingService : SPDiagnosticsServiceBase { 
    private LoggingService() : 
      base("MSDN Logging Service", SPFarm.Local) { }
  }
}

Als Nächstes implementieren Sie die ProvideAreas-Methode, mit der der Produktname und die verfügbaren Protokollierungskategorien registriert werden, wie im folgenden Beispiel gezeigt.

public const string MSDN_INFO = "MSDN Info";
public const string MSDN_ERROR = "MSDN Error";
private static string PRODUCT_DIAGNOSTIC_NAME = "MSDN Sample";

protected override IEnumerable<SPDiagnosticsArea> ProvideAreas() {
  List<SPDiagnosticsArea> areas = new List<SPDiagnosticsArea>{
    new SPDiagnosticsArea(PRODUCT_DIAGNOSTIC_NAME, new List<SPDiagnosticsCategory>{
      new SPDiagnosticsCategory(MSDN_INFO, TraceSeverity.Verbose, EventSeverity.Information),
      new SPDiagnosticsCategory(MSDN_ERROR, TraceSeverity.Unexpected, EventSeverity.Warning),
    })
  };

  return areas;
}

Im folgenden Beispiel wird der letzte Schritt gezeigt: Sie gestalten den benutzerdefinierten Protokollierungsdienst benutzerfreundlich, indem Sie einige statische Methoden hinzufügen, die von benutzerdefinierten Komponenten wie etwa Webparts aufgerufen werden können.

private static LoggingService _current;
public static LoggingService Current {
  get {
    if (_current == null)
      _current = new LoggingService();
    return _current;
  }
}

public static void LogMessage(string categoryName, string message) {
  SPDiagnosticsCategory category = 
  LoggingService.Current.Areas[PRODUCT_DIAGNOSTIC_NAME].Categories[categoryName];
  LoggingService.Current.WriteTrace(0, category, TraceSeverity.Verbose, message);
}

public static void LogError(string categoryName, string message) {
  SPDiagnosticsCategory category = 
  LoggingService.Current.Areas[PRODUCT_DIAGNOSTIC_NAME].Categories[categoryName];
  LoggingService.Current.WriteTrace(0, category, TraceSeverity.Unexpected, message);
}

Testen Sie die Protokollierung, indem Sie dem Projekt eine benutzerdefinierte Komponente hinzufügen, z. B. ein Webpart, und den Protokollierungsdienst aufrufen, wie im folgenden Beispiel gezeigt.

public class WriteToUlsFarmSolutionWebPart : WebPart {
  protected override void CreateChildControls() {
    Button logInfoButton = new Button { Text = "log info entry" };
    logInfoButton.Click += (sender, e) => 
      LoggingService.LogMessage(LoggingService.MSDN_INFO, "Sample info message.");
    this.Controls.Add(logInfoButton);

    Button logErrorButton = new Button { Text = "log error entry" };
    logErrorButton.Click += (sender, e) =>
      LoggingService.LogMessage(LoggingService.MSDN_ERROR, "Sample error message.");
    this.Controls.Add(logErrorButton);
  }
}

Wird der obige Code durch Klicken auf eine der Schaltflächen im Webpart ausgeführt, wird der SharePoint-Protokolldatei ein neuer Eintrag unter Verwendung des Produktnamens MSDN Sample und einer der neuen Kategorien hinzugefügt.

Schreiben in die ULS-Protokolle aus Sandkastenlösungen

Leider ist es nicht möglich, von einer Lösung mit eingeschränkter Sicherheitsstufe aus direkt in die ULS-Protokolle zu schreiben. Der Grund hierfür ist, dass die Lösung mit eingeschränkter Sicherheitsstufe vom isolierten Benutzercodedienst aus keinen Zugriff auf den Protokollierungsdienst hat. Entwickler können jedoch einen voll vertrauenswürdigen Proxy erstellen, der als Farmlösung bereitgestellt wird. Dann könnte eine beliebige Lösung mit eingeschränkter Sicherheitsstufe diesen voll vertrauenswürdigen Proxy nutzen. Eine exemplarische Vorgehensweise für das Erstellen eines voll vertrauenswürdigen Proxys finden Sie unter How To: Create and Register a Sandbox Proxy.

Erstellen Sie mithilfe der SharePoint-Entwicklungstools in Microsoft Visual Studio 2010 eine Farmlösung, und erstellen Sie die gleiche SPDiagnosticsServiceBase-Protokollierungsklasse, die auch schon zuvor erstellt wurde. Der nächste Schritt besteht darin, Im nächsten Schritt erstellen Sie den Proxy, von dem der Protokollierungsdienst aufgerufen wird.

Fügen Sie dem Projekt eine weitere Klasse hinzu, die die Argumente für den Proxyvorgang annimmt, wie im folgenden Beispiel gezeigt.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.UserCode;

namespace MSDN.SharePoint.Samples.WriteToUls {
  [Serializable]
  public class LoggingMessageProxyArguments : SPProxyOperationArgs {
    public string MessageCategoryName { get; set; }
    public string MessageContents { get; set; }

    public static string LoggingProxyOperationTypeName {
      get {
        return "LoggingProxy.LoggingMessageProxyOperation";
      }
    }

    public static string LoggingProxyAssemblyName {
      get {
        return "MSDN.SharePoint.Samples.WriteToUlsSandboxSolution.Proxy, Version=1.0.0.0, Culture=neutral, PublicKeyToken=[INSERT PROJECT'S PUBLICKEYTOKEN HERE]";
      }
    }
  }
}

Fügen Sie als Nächstes dem Projekt eine weitere Klasse hinzu, die den voll vertrauenswürdigen Vorgang ausführt, wie im folgenden Beispiel gezeigt.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.UserCode;

namespace MSDN.SharePoint.Samples.WriteToUls {
  public class LoggingMessageProxyOperation : SPProxyOperation {
    public override object Execute(SPProxyOperationArgs args) {
      LoggingMessageProxyArguments proxyArguments = args as LoggingMessageProxyArguments;

      string loggingCategory ;
      switch (proxyArguments.MessageCategoryName.ToLower()) {
        case LoggingService.MSDN_ERROR:
          loggingCategory = LoggingService.MSDN_ERROR;
          break;
        default:
          loggingCategory = LoggingService.MSDN_INFO;
          break;
      }

      // Do full trust action.
      LoggingService.LogMessage(loggingCategory, proxyArguments.MessageContents);
    }
  }
}

Nachdem Sie die Argumente und den Vorgang für den Proxy erstellt haben, besteht der letzte Schritt darin, ihn beim Benutzercodedienst in der Farm zu registrieren. Dies kann mithilfe des aktivierten Ereignisses in einem Feature für den Farmbereich geschehen, wie im folgenden Beispiel dargestellt.

public class LoggingMessageProxyInstallerEventReceiver : SPFeatureReceiver {
  public override void FeatureActivated(SPFeatureReceiverProperties properties) {
    // Get proxy operation.
    LoggingMessageProxyOperation proxyOperation = new SPProxyOperationType(
                                LoggingMessageProxyArguments.LoggingProxyAssemblyName,
                                LoggingMessageProxyArguments.LoggingProxyOperationTypeName);

    SPUserCodeService ucService = SPUserCodeService.Local;
    ucService.ProxyOperationTypes.Add(proxyOperation);
    ucService.Update();
  }

  public override void FeatureDeactivating(SPFeatureReceiverProperties properties) {
    // Get proxy operation.
    LoggingMessageProxyOperation proxyOperation = new SPProxyOperationType(
                                LoggingMessageProxyArguments.LoggingProxyAssemblyName,
                                LoggingMessageProxyArguments.LoggingProxyOperationTypeName);

    // Add proxy to user code service.
    SPUserCodeService ucService = SPUserCodeService.Local;
    ucService.ProxyOperationTypes.Remove(proxyOperation);
    ucService.Update();
  }
}

Nachdem Sie dieses Projekt bereitgestellt und das darin enthaltene Feature für den Farmbereich aktiviert haben, kann der Proxy aus einer Lösung mit eingeschränkter Sicherheitsstufe aufgerufen werden. Im folgenden Code wird veranschaulicht, wie ein Webpart, das in einer Lösung mit eingeschränkter Sicherheitsstufe bereitgestellt ist, den voll vertrauenswürdigen Proxy verwenden und in die SharePoint 2010-ULS-Protokolle schreiben kann.

public class WriteToUlsSandboxSolutionWebPart : WebPart {
  protected override void CreateChildControls() {
    LoggingMessageProxyArguments loggingProxyArgs = new LoggingMessageProxyArguments();

    Button logInfoButton = new Button { Text = "log info entry" };
    logInfoButton.Click += (sender, e) => {
      loggingProxyArgs.MessageCategoryName = LoggingService.MSDN_INFO;
      loggingProxyArgs.MessageContents = "Sample info message";
      var result1 = SPUtility.ExecuteRegisteredProxyOperation(
        LoggingMessageProxyArguments.LoggingProxyAssemblyName,
        LoggingMessageProxyArguments.LoggingProxyOperationTypeName,
        loggingProxyArgs);
    };
    this.Controls.Add(logInfoButton);

    Button logErrorButton = new Button { Text = "log error entry" };
    logInfoButton.Click += (sender, e) => {
      loggingProxyArgs.MessageCategoryName = LoggingService.MSDN_ERROR;
      loggingProxyArgs.MessageContents = "Sample info message";
      var result2 = SPUtility.ExecuteRegisteredProxyOperation(
        LoggingMessageProxyArguments.LoggingProxyAssemblyName,
        LoggingMessageProxyArguments.LoggingProxyOperationTypeName,
        loggingProxyArgs);
    };
    this.Controls.Add(logErrorButton);
  }
}

Hinweise zum Schreiben des Protokollierungsereignisses und der Ablaufverfolgungsereignisse in die ULS-Protokolle finden Sie unter Sicherheitsstufen der Ablauf- und Ereignisprotokollierung im SharePoint 2010 SDK

Fehlerberichterstattung in SharePoint 2010

Für Entwickler ist es empfehlenswert, benutzerdefinierte Projekte mit umfangreichen Protokollierungsinformationen auszustatten, da sie etwaige Probleme anhand dieser Informationen lokalisieren und beheben können. Allerdings werden immer noch Fehler auftreten, die Entwickler zurückverfolgen müssen. Außerdem kann es sein, dass Entwickler bestimmte Standardsystemseiten ändern möchten, die in SharePoint 2010 verwendet werden. Beide Szenarien werden in den folgenden Abschnitten beschrieben.

Verwenden der Datei "web.config" der Webanwendung

Wenn in einer ASP.NET-Anwendung Fehler auftreten, werden diese entweder im Rohstatus angezeigt (wenn die Datei web.config das Element <customErrors mode="Off" /> enthält) oder mithilfe einer benutzerdefinierten Fehlerseite, auf der die Details des Fehlers ausgeblendet sind und eine benutzerdefinierte Meldung angezeigt wird (wenn die Datei web.config das Element <customErrors mode="On" /> enthält).

Gemäß der Standardkonfiguration in SharePoint 2010 sind benutzerdefinierte Fehler aktiviert, und die Details der Fehlermeldung werden nicht angezeigt. Dies hat u. a. den Vorteil, dass die Benutzer nicht mit kryptischen Fehlermeldungen konfrontiert werden, sondern stattdessen eine leichter verständliche, benutzerfreundlichere Fehlerseite sehen. Ein weiterer Grund dafür, nicht alle Details anzuzeigen, liegt darin, dass die Anzeige aller Einzelheiten eines Fehlers eine Sicherheitslücke darstellen könnte, da hierbei u. U. mehr Informationen verfügbar gemacht werden, als den Benutzern gegenüber offengelegt werden sollten.

Leider reicht die Detailgenauigkeit der benutzerdefinierten Fehlermeldungen von SharePoint manchmal nicht aus, um Entwicklern die Möglichkeit der Behebung des Problems zu geben. Beim Erstellen von benutzerdefinierten Lösungen ist es hilfreich, den vollständigen Fehlertext einschließlich der konkreten Ausnahme, der Ausnahmemeldung und des vollständigen Aufrufliste zu sehen. Dies können Sie ganz einfach erreichen, indem Sie die Datei web.config der Webanwendung ändern und den Modus im <customErrors />-Element auf Off umstellen. Dadurch wird die ASP.NET-Rohfehlerseite für die gesamte Webanwendung angezeigt. Sie können diesen Prozess mithilfe eines Features für den Webanwendungsbereich automatisieren, indem Sie die aktivierten und deaktivierten Ereignisse des Features implementieren, um diese Änderung durchzuführen. Dies wird im folgenden Beispiel gezeigt.

public override void FeatureActivated(SPFeatureReceiverProperties properties) {
  SPWebApplication WebApp = (SPWebApplication)properties.Feature.Parent;
  foreach (ModificationEntry modEntry in Entries) {
    WebApp.WebConfigModifications.Add(
      CreateModification(modEntry)
    );
  }
  WebApp.WebService.ApplyWebConfigModifications();
}

public override void FeatureDeactivating(SPFeatureReceiverProperties properties) {
  SPWebApplication WebApp = (SPWebApplication)properties.Feature.Parent;
  foreach (ModificationEntry modEntry in Entries) {
    WebApp.WebConfigModifications.Remove(
      CreateModification(modEntry)
    );
  }
  WebApp.WebService.ApplyWebConfigModifications();
}

private struct ModificationEntry {
  public string Name;
  public string XPath;
  public string Value;
  public SPWebConfigModification.SPWebConfigModificationType ModType;
  // Parameterized contructor.
  public ModificationEntry(
      string Name, string XPath, string Value,
      SPWebConfigModification.SPWebConfigModificationType ModType) {
    // Intialize structure instances.
    this.Name = Name;
    this.XPath = XPath;
    this.Value = Value;
    this.ModType = ModType;
  }
}

private ModificationEntry[] Entries = {
  new ModificationEntry( 
    "mode", "configuration/system.web/customErrors", "Off", 
    SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute)
 };

private SPWebConfigModification CreateModification(ModificationEntry modEntry) {
  // Create and return SPWebConfigModification object.
  SPWebConfigModification modification;
  modification = new SPWebConfigModification(modEntry.Name, modEntry.XPath);
  modification.Owner = "MSDN.SharePointDebugger";
  modification.Sequence = 0;
  modification.Type = modEntry.ModType;
  modification.Value = modEntry.Value;
  return modification;
}

Verwenden der Datei "web.config" im Ordner "Layouts"

Bedenken Sie immer, dass die Ordner in einer Webanwendung die Einstellungen in der Datei web.config von ihren übergeordneten Ordnern erben, sofern sie nicht von einer lokalen Datei web.config überschrieben werden. Im Falle von SharePoint 2010 enthält der Ordner http://.../_layouts eine eigene Datei web.config, in der die benutzerdefinierten Fehler aktiviert sind. Daher empfiehlt es sich beim Erstellen von benutzerdefinierten Anwendungsseiten oder Beheben von Fehlern auf den SharePoint 2010-Anwendungsseiten u. U., entweder die im Ordner {SharePoint Root}\TEMPLATE\LAYOUTS befindliche Datei web.config zu ändern oder eine benutzerdefinierte Datei web.config hinzuzufügen, durch die benutzerdefinierte Fehler in dem Ordner mit den benutzerdefinierten Anwendungsseiten deaktiviert werden.

Benutzerdefinierte SharePoint-Anwendungsseiten

SharePoint 2010 umfasst zahlreiche Systemanwendungsseiten für Elemente wie Fehlermeldungen, Meldungen über verweigerten Zugriff und An- und Abmeldeseiten. In früheren Versionen von SharePoint waren diese Dateien hartcodiert. Manche ließen sich sehr einfach ändern, z. B. die Anmeldeseite (über die Datei web.config), andere konnten nur unter Einsatz äußerst kreativen Codes geändert werden.

Dies hat Microsoft in SharePoint 2010 verbessert: Hier haben Entwickler die Möglichkeit, die URL einer benutzerdefinierten Seite abzurufen und eigene Systemanwendungsseiten zu erstellen. Die so erstellten benutzerdefinierten Systemanwendungsseiten können benutzerdefinierte Geschäftslogik enthalten oder so gestaltet werden, dass sie dem Branding der restlichen Website entsprechen. Diese Änderungen können mithilfe von zwei Methoden in eine Webanwendung übernommen werden: GetMappedPage und UpdateMappedPage. Eine Liste der verfügbaren Systemanwendungsseiten, die geändert werden können, finden Sie in der SPWebApplication.SPCustomPage-Enumeration.

Die Änderung einer Systemgestaltungsvorlage wird am besten in den aktivierten und deaktivierten Ereignissen eines Features für den Webanwendungsbereich implementiert. Als Erstes erstellen Sie eine neue Anwendungsseite, die als benutzerdefinierte Systemanwendungsseite dient. Im nächsten Schritt erstellen Sie ein Feature für den Webanwendungsbereich und implementieren die aktivierten und deaktivierten Ereignisse, wie im folgenden Beispiel gezeigt.

public class CustomErrorPagesEventReceiver : SPFeatureReceiver {
  public override void FeatureActivated(SPFeatureReceiverProperties properties)
  {
    SPWebApplication webApp = properties.Feature.Parent as SPWebApplication;
    if (webApp != null) {
      // Set Access Denied.
      if (!webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.AccessDenied, 
          "/_layouts/CustomErrorPages/AccessDenied.aspx")) {
        throw new ApplicationException("Failed setting new access denied page mapping.");
      }

      // Set Signout.
      if (!webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.Signout, 
          "/_layouts/CustomErrorPages/Signout.aspx")) {
        throw new ApplicationException("Failed setting new signout page mapping.");
      }

      // Set File Not Found.
      webApp.FileNotFoundPage = "/_layouts/1033/FileNotFound.htm";

      webApp.Update(true);
    }
  }

  public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
  {
    SPWebApplication webApp = properties.Feature.Parent as SPWebApplication;
    if (webApp != null) {
      webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.AccessDenied, null);
      webApp.UpdateMappedPage(SPWebApplication.SPCustomPage.Signout, null);
        webApp.FileNotFoundPage = null;
    }
  }
}

Entwicklerdashboard in SharePoint 2010

Das Entwicklerdashboard ist eine weitere Neuerung in SharePoint 2010, die Entwicklern bei der Protokollierung und beim Debuggen von benutzerdefinierten Komponenten hilft, die zu SharePoint-Seiten hinzugefügt werden. Das Entwicklerdashboard kann für eine ganze Farm aktiviert werden, um eine Momentaufnahme der Aktivität und Leistung einer bestimmten Seitenanforderung zu erstellen.

Abbildung 1. Entwicklerdashboard

Das Entwicklerdashboard erweist sich oft als sehr nützlich bei der Problembehandlung für Komponenten auf einer Seite, da eine einzige SharePoint-Seite zahlreiche benutzerdefinierte Komponenten enthalten kann. Ist dies der Fall, und die Leistung einer Seite ist schlechter als erwartet, so kann die Komponente, die die Ursache für die Verlangsamung ist, oft nur schwer auf andere Weise als im Ausschlussverfahren isoliert werden. Genau in dieser Situation ist das Entwicklerdashboard hilfreich.

Das Entwicklerdashboard enthält unterschiedliche Kategorien von Informationen. Es bietet Details zur Dauer der Verarbeitung von Threads, zur Menge und Ausführungsdauer von SQL Server-Datenbankaufrufen und Windows Communication Foundation (WCF)-Dienstaufrufen, zur URL, zum aktuellen Benutzer usw.

Konfigurieren des Entwicklerdashboards

Das Entwicklerdashboard ist standardmäßig nicht aktiviert. Sie aktivieren das Entwicklerdashboard entweder über die API oder mithilfe eines benutzerdefinierten Windows PowerShell-Skripts, wie im folgenden Beispiel dargestellt.

$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$dashboardSetting = $contentService.DeveloperDashboardSettings
$dashboardSetting.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::On
$dashboardSetting.Update()

Für das Entwicklerdashboard stehen zwei verschiedene Anzeigeebenen zur Verfügung. Mit der SPDeveloperDashboardLevel.On-Enumerationsoption wird das Dashboard auf allen Seiten in einer Farm aktiviert. Wird die Option SPDeveloperDashboardLevel.OnDemand festgelegt, bleibt das Dashboard deaktiviert, allerdings wird ein Bild ähnlich einem Leistungsindikator in der rechten oberen Ecke der Seite eingefügt. Klickt der Benutzer auf dieses Bild, wird ein Postback ausgelöst, durch das das Entwicklerdashboard der Seite hinzugefügt wird.

Informationen zum Entwicklerdashboard finden Sie unter Verwenden des Entwicklerdashboards im SharePoint 2010 SDK.

Das Entwicklerdashboard bietet Entwicklern eine Fülle von Informationen für SharePoint-Prozesse. Entwickler können jedoch auch eigene Protokollierungsfunktionen in benutzerdefinierten Komponenten hinzufügen, die im Dashboard angezeigt werden.

Schreiben in das Entwicklerdashboard

Es kann nur direkt von Farmlösungen aus in das Entwicklerdashboard geschrieben werden. Lösungen mit eingeschränkter Sicherheitsstufe können nicht in das Entwicklerdashboard schreiben, da sie im Benutzercodeprozess isoliert sind. Damit in das Entwicklerdashboard geschrieben werden kann, sollten Sie eine benutzerdefinierte Komponente in ein SPMonitoredScope-Objekt einbinden.

Im folgenden Code wird veranschaulicht, wie in das Entwicklerdashboard geschrieben werden kann und wie geschachtelte Bereiche erstellt werden.

public class MonitoredWebPart : WebPart {
  protected override void CreateChildControls() {
    using (SPMonitoredScope scope = new SPMonitoredScope("MonitoredWebPart.CreateChildControls")) {
      this.Controls.Add(
        new LiteralControl("Turn on the developer dashboard to see entries logged by this Web Part.");

        // Trigger a SPRequest & DB round trip.
        TriggerSpDatabaseRequest();
        TriggerSPRequestObject();

        // Simulate a delay.
        TriggerSimulatedDelay();
      );
    }
  }
  private void TriggerSpDatabaseRequest() {
    using (SPMonitoredScope scope = new SPMonitoredScope("MonitoredWebPart.TriggerSpDatabaseRequest")) {
      SPList someList = SPContext.Current.Web.Lists[0];
      int itemsinList = someList.Items.Count();
    }
  }

  private void TriggerSPRequestObject() {
    using (SPMonitoredScope scope = new SPMonitoredScope("MonitoredWebPart.TriggerSPRequestObject")) {
      using (SPSite siteCollection = new SPSite(SPContext.Current.Site.Id)) {
        string siteCollectionUrl = siteCollection.RootWeb.Url;
      }
    }
  }

  private void TriggerSimulatedDelay() {
    using (SPMonitoredScope scope = new SPMonitoredScope("MonitoredWebPart.TriggerSimulatedDelay")) {
      System.Threading.Thread.Sleep(2000);
    }
  }
}

Abbildung 2 zeigt die Ergebnisse des Hinzufügens des Webparts aus dem vorherigen Codebeispiel zur Seite.

Abbildung 2. Schreiben in das Entwicklerdashboard

Hinzufügen des Entwicklerdashboards zu benutzerdefinierten Gestaltungsvorlagen

Das Entwicklerdashboard ist in allen SharePoint-Websites enthalten, in denen eine der Gestaltungsvorlagen von SharePoint 2010 verwendet wird. Beim Erstellen von benutzerdefinierten Gestaltungsvorlagen können Entwickler das Entwicklerdashboard hinzufügen, indem sie einfach das folgende Serversteuerelement hinzufügen, idealerweise am unteren Seitenrand:

<SharePoint:DeveloperDashboard runat="server" />

Wenn das Entwicklerdashboard auf SPDeveloperDashboardLevel.OnDemand festgelegt ist, verwendet es den Dashboard-Starter, um das Symbol anzuzeigen und das Dashboard zu rendern. Es empfiehlt sich außerdem, den das folgende Steuerelement in die benutzerdefinierten Gestaltungsvorlagen einzufügen:

<SharePoint:DeveloperDashboardLauncher runat="server" />

Dieses Steuerelement enthält einige öffentliche Eigenschaften zum Ändern der Position, des Texts und des Bilds, mit dem das Steuerelement gerendert wird. Diese finden Sie in der DeveloperDashboardLauncher-Klasse im SharePoint 2010 SDK.

Schlussbemerkung

Microsoft hat für das neueste Release von SharePoint, Microsoft SharePoint 2010, großen Aufwand in die Verbesserung der Tools für Entwickler gesteckt. Zusätzlich zu den hervorragenden Entwicklertools in Visual Studio 2010 hat Microsoft das Produkt mit erheblich mehr Flexibilität und Funktionen ausgestattet, damit Entwickler Protokollierungs- und Debuggingverfahren in benutzerdefinierte Lösungen einbinden können, die sie für SharePoint 2010 erstellt haben. In diesem Artikel wird der Leser durch einige gängige Protokollierungs- und Debuggingverfahren geführt, die Entwicklern jetzt beim Erstellen von SharePoint 2010-Lösungen zur Verfügung stehen.

Weitere Ressourcen

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Protokollierung für SharePoint-Entwickler

• Konfigurieren der Diagnoseprotokollierung (SharePoint Foundation 2010) (TechNet)

• Referenz für Zeitgeberaufträge (SharePoint Server 2010) (TechNet)

• Datenbanktypen und -beschreibungen (SharePoint Server 2010) (TechNet)

• Verwenden von Business Connectivity Services zum Anzeigen von SharePoint 2010-ULS-Protokollen

• SharePoint-ULS-Protokollanzeige

• Leitfaden für SharePoint

• Verwenden des Entwicklerdashboards

• SharePoint Developer Center