Fonctionnalités de débogage et de journalisation dans SharePoint 2010

  • Article

Résumé : découvrez les nouvelles fonctionnalités de journalisation et de débogage de SharePoint Foundation 2010 qui permettent aux développeurs de créer des solutions plus fiables et plus faciles à tester.

Dernière modification : mercredi 12 janvier 2011

S’applique à : Business Connectivity Services | Office 2010 | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Dans cet article
Introduction au débogage et à la journalisation dans SharePoint 2010
Journalisation dans SharePoint 2010
Signalement d’erreurs dans SharePoint 2010
Pages d’applications SharePoint personnalisées
Tableau de bord du développeur SharePoint 2010
Conclusion
Ressources supplémentaires

Sommaire

  • Introduction au débogage et à la journalisation dans SharePoint 2010

  • Journalisation dans SharePoint 2010

  • Signalement d’erreurs dans SharePoint 2010

  • Pages d’applications SharePoint personnalisées

  • Tableau de bord du développeur SharePoint 2010

  • Conclusion

  • Ressources supplémentaires

Cliquez pour obtenir le code   Télécharger le code (éventuellement en anglais)

Introduction au débogage et à la journalisation dans SharePoint 2010

Microsoft SharePoint 2010 est un produit très complet que les développeurs peuvent personnaliser en fonction de leurs différents besoins professionnels. SharePoint étant basé sur Microsoft ASP.NET, il offre aux développeurs les mêmes options de débogage et de journalisation que celles accessibles pour les sites Web ASP.NET traditionnels. Au-delà de celles proposées par ASP.NET, SharePoint 2010 offre de nouvelles options de débogage et de journalisation destinées à aider les développeurs à analyser et dépanner les applications.

Cet article traite de différents aspects et technologies de journalisation et de débogage que les développeurs peuvent utiliser dans leurs applications SharePoint 2010 personnalisées.

Nouveautés dans SharePoint Server 2010 en matière de journalisation et de débogage

Les meilleures applications offrent un bon niveau de journalisation afin d’assister les développeurs à effectuer le suivi des erreurs lorsque les choses ne fonctionnent pas comme prévu ou lorsque des événements inattendus se produisent. Microsoft Office SharePoint Server 2007 mettait à la disposition des développeurs tous les outils disponibles dans ASP.NET, tels que le journal de suivi et de débogage. Les développeurs pouvaient également écrire dans le journal SharePoint, appelé Service de journalisation unifiée (ULS, Unified Logging Service), mais des tâches supplémentaires étaient nécessaires pour écrire directement dans les fichiers journaux.

Microsoft a ajouté d’autres fonctionnalités de journalisation et de débogage à SharePoint 2010 afin d’aider les développeurs à inclure davantage d’analyse et de dépannage dans leurs applications personnalisées. Cet article traite des nouveaux sujets suivants dans SharePoint 2010 :

  • Jetons de corrélation

  • Base de données de journalisation

  • Pages d’erreur personnalisées

  • Tableau de bord du développeur

Journalisation dans SharePoint 2010

Chaque serveur exécutant Windows SharePoint Services 3.0 et Office SharePoint Server 2007 écrivait des informations de journalisation dans les fichiers journaux ULS et le journal des événements de serveur. Les fichiers journaux ULS, stockés dans le dossier {SharePoint Root}\LOGS sur chaque serveur exécutant SharePoint dans la batterie, pouvaient contenir une quantité non négligeable d’informations, selon la façon dont le seuil de journalisation de diagnostic était configuré. Même s’il est souvent préférable de disposer de trop de détails de journalisation plutôt que pas assez, il peut être difficile de trouver une entrée spécifique dans les fichiers journaux. SharePoint 2010 simplifie cette tâche de recherche d’entrées de journaux en assignant un caractère unique à chaque entrée de journal. Ce caractère unique, appelé jeton de corrélation, est un GUID présenté à l’utilisateur lorsqu’une erreur se produit. Un administrateur ou développeur peut alors utiliser cette chaîne de GUID mentionnée dans l’erreur pour rechercher une entrée spécifique dans le fichier journal. Cela permet d’accélérer le processus de recherche d’entrée dans les fichiers journaux pour le suivi d’incidents spécifiques.

Le service ULS peut également être configuré de façon à déterminer la quantité de détails offerte par les fichiers journaux et le journal des événements, en fonction de critères spécifiques. L’article Configurer la journalisation des diagnostics (SharePoint Foundation 2010) (Microsoft TechNet) explique comment configurer la journalisation des diagnostics dans SharePoint 2010.

Base de données de journalisation SharePoint

L’une des autres nouveautés introduites par Microsoft est une base de données qui contient toutes les informations de journalisation pour tous les serveurs de la batterie. On utilise pour cela quelques nouveaux travaux du minuteur. Une fois ces travaux activés (ils sont tous désactivés par défaut), SharePoint insère les données de journalisation des diagnostics dans une nouvelle base de données Microsoft SQL Server. Voici la liste des nouveaux travaux du minuteur :

  • Fournisseur de données de diagnostic : journal des événements

  • Fournisseur de données de diagnostic : compteurs de performances - Serveurs de base de données

  • Fournisseur de données de diagnostic : Compteurs de performance - Sites Web frontaux

  • Fournisseur de données de diagnostic : requêtes de blocage SQL

  • Fournisseur de données de diagnostic : DMV SQL

  • Fournisseur de données de diagnostic : DMV de mémoire SQL

  • Fournisseur de données de diagnostic : journal de suivi

Les détails relatifs à chacun de ces travaux du minuteur sont documentés dans Informations de référence sur les travaux du minuteur (SharePoint Server 2010). L’un des avantages majeurs offerts par l’activation de ces travaux est le fait que tous les différents journaux sont agrégés en un emplacement unique qui peut être interrogé à partir de différentes sources. Le contenu de cette base de données de journalisation pourrait même être exposé à l’aide de listes et de types de contenu externe Microsoft Business Connectivity Services (BCS).

Lecture des journaux ULS SharePoint

Outre la nouvelle base de données de journalisation dans SharePoint 2010, les développeurs peuvent également analyser les fichiers journaux SharePoint bruts créés dans le dossier {SharePoint Root}\LOGS sur chaque serveur. Lors du développement de solutions, les développeurs travaillent généralement dans un environnement isolé où tout est installé sur un serveur unique plutôt que sur une batterie composée de différents serveurs. Les fichiers journaux sont simplement de gros fichiers texte délimités de largeur fixe pouvant être lus et consultés à l’aide d’un éditeur de texte quelconque.

Par ailleurs, de nombreux développeurs ont publié différents utilitaires qui facilitent la lecture des fichiers journaux SharePoint. Une recherche rapide des termes SharePoint ULS viewer donne accès à de nombreuses ressources. Certains de ces utilitaires incluent des notifications et simplifient grandement la recherche et le filtrage à l’aide de critères spécifiques, comparé à l’utilisation d’un éditeur de texte standard.

Écriture dans les journaux ULS SharePoint

La lecture des journaux ULS SharePoint est utile lors du dépannage des messages générés par SharePoint, mais l’une des choses dont les développeurs ont réellement besoin est la capacité à écrire leurs propres messages dans les fichiers journaux. Microsoft rend beaucoup plus simple l’écriture dans les fichiers journaux dans SharePoint 2010 grâce à l’utilisation de la classe SPDiagnosticsService, comme l’illustre l’exemple suivant.

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

L’extrait de code précédent écrit les détails des exceptions dans le journal ULS de SharePoint. Lors de l’inspection de l’entrée ajoutée, les développeurs remarqueront que l’entrée de la colonne Produit est Inconnu. Il s’agit du comportement par défaut de la classe SPDiagnosticsService. Pour ajouter des noms de produits personnalisés, vous pouvez implémenter votre propre service de diagnostics à l’aide de la classe SPDiagnosticsServiceBase. Malheureusement, l’interaction avec un SPDiagnosticsService personnalisé est disponible uniquement dans les solutions de batterie entièrement fiables, et non dans les solutions en bac à sable (sandbox). Pour écrire dans les journaux ULS à l’aide de la classe SPDiagnosticsService à partir du sandbox, vous pouvez créer un proxy entièrement fiable pouvant être appelé par les solutions en bac à sable (sandbox). Les deux sections suivantes expliquent comment écrire dans les journaux ULS de SharePoint.

Au-delà de la solution consistant à écrire une classe SPDiagnosticsService personnalisée, le groupe Microsoft patterns & practices a publié le package d’instructions Développement d’applications pour SharePoint 2010 (éventuellement en anglais), qui comprend un enregistreur d’événements SharePoint. Les développeurs se doivent de prendre en compte toutes ces approches lors de la création d’applications personnalisées.

Création d’un service de journalisation personnalisé

La création d’un service de journalisation personnalisé dans une application personnalisée nécessite de créer une nouvelle implémentation de la classe SPDiagnosticsServiceBase, de substituer une méthode unique et de fournir quelques moyens d’écrire dans les fichiers journaux.

L’exemple suivant montre comment ajouter une nouvelle classe à une solution autre qu’une solution en bac à sable (sandbox) et faire en sorte que cette classe hérite de la classe SPDiagnosticsServiceBase.

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) { }
  }
}

Ensuite, implémentez la méthode ProvideAreas qui inscrira le nom du produit et les catégories de journalisation disponibles, comme illustré dans l’exemple suivant.

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;
}

L’exemple suivant montre la dernière étape, qui consiste à simplifier l’utilisation du service de journalisation personnalisé en ajoutant quelques méthodes statiques pouvant être appelées à partir de composants personnalisés, tels que des composants WebPart.

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);
}

Testez l’enregistreur d’événements en ajoutant un composant personnalisé au projet (par exemple un composant WebPart) et appelez le service de journalisation, comme illustré dans l’exemple suivant.

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);
  }
}

Lorsque vous exécutez le code précédent en cliquant sur l’un des boutons du composant WebPart, une nouvelle entrée est ajoutée au fichier journal de SharePoint avec le nom de produit MSDN Sample et l’une des nouvelles catégories.

Écriture dans les journaux ULS à partir de solutions en bac à sable (sandbox)

Malheureusement, il est impossible d’écrire directement dans les journaux ULS à partir d’une solution en bac à sable (sandbox) car la solution en bac à sable (sandbox) n’a pas accès au service de journalisation à partir du service de code utilisateur isolé. Néanmoins, vous pouvez créer un proxy entièrement fiable déployé en tant que solution de batterie, dont toute solution en bac à sable (sandbox) pourra tirer parti. Pour obtenir une procédure pas à pas expliquant comment créer un proxy entièrement fiable, voir How To: Create and Register a Sandbox Proxy.

Créez une solution de batterie à l’aide des Outils de développement SharePoint dans Microsoft Visual Studio 2010 et créez la même classe de journalisation SPDiagnosticsServiceBase que celle créée précédemment. L’étape suivante consiste à créer le proxy qui appellera le service de journalisation.

Ajoutez au projet une autre classe qui prendra les arguments d’opérations de proxy, comme indiqué dans l’exemple suivant.

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]";
      }
    }
  }
}

Ensuite, ajoutez au projet une autre classe qui exécute l’opération entièrement fiable, comme indiqué dans l’exemple suivant.

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);
    }
  }
}

L’opération et les arguments du proxy étant créés, la dernière étape consiste à l’inscrire auprès du service de code utilisateur dans la batterie. Pour cela, vous pouvez utiliser l’événement activé dans une fonctionnalité de batterie, comme indiqué dans l’exemple suivant.

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();
  }
}

Une fois que ce projet a été déployé et que la fonctionnalité de batterie incluse a été activée, le proxy peut être appelé à partir d’une solution en bac à sable (sandbox). Le code suivant illustre comment un composant WebPart déployé dans une solution en bac à sable (sandbox) peut utiliser le proxy entièrement fiable et écrire dans les journaux ULS de SharePoint 2010.

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);
  }
}

Pour plus d’informations sur la façon d’écrire l’événement de journalisation et d’effectuer le suivi des événements, voir Niveaux de gravité du journal de suivi et du journal des événements dans le kit SDK SharePoint 2010

Signalement d’erreurs dans SharePoint 2010

L’ajout de copieuses quantités d’éléments de journalisation aux projets personnalisés est une bonne idée pour les développeurs, car cela aide à effectuer le suivi des problèmes lorsqu’ils se produisent. Toutefois, il arrive toujours que certaines erreurs doivent être suivies. Par ailleurs, il se peut que vous souhaitiez modifier certaines des pages système par défaut utilisées par SharePoint 2010. Les sections suivantes décrivent ces deux scénarios.

Utilisation du fichier web.config de l’application Web

Lorsque des erreurs se produisent dans une application ASP.NET, elles sont affichées soit dans leur état brut (lorsque le fichier web.config contient l’élément <customErrors mode="Off" />), soit par le biais d’une page d’erreur personnalisée afin de masquer les détails de l’erreur et d’afficher un message personnalisé (lorsque le fichier web.config contient l’élément <customErrors mode="On" />).

La configuration par défaut dans SharePoint 2010 consiste à activer les erreurs personnalisées et à ne pas afficher les détails de l’erreur, non seulement car il est préférable que les utilisateurs reçoivent un message d’erreur convivial, mais également parce que fournir les détails complets sur une erreur pourrait être considéré comme une faille de sécurité car susceptible d’exposer davantage d’informations qu’il ne faudrait.

Malheureusement, les messages d’erreur personnalisés fournis par SharePoint ne sont pas toujours assez détaillés pour permettre aux développeurs de résoudre le problème. Lors de la création d’applications personnalisées, il peut être utile de voir l’erreur complète, y compris l’exception spécifique, le message d’exception et la pile des appels complète. Il suffit pour cela de modifier le fichier web.config de l’application Web en affectant à l’élément <customErrors /> la valeur Off. Cela permet d’afficher la page d’erreur ASP.NET brute pour toute l’application Web. Ce processus peut également être automatisé au moyen d’une fonctionnalité d’application Web, en implémentant les événements « activé » et « désactivé » de la fonctionnalité, comme indiqué dans l’exemple suivant.

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;
}

Utilisation du fichier web.config Layout

Il convient de garder à l’esprit que les dossiers d’une application Web héritent des paramètres du fichier web.config de leurs dossiers parents, à moins qu’ils ne soient remplacés par un fichier web.config local. Spécifique à SharePoint 2010, le dossier http://.../_layouts contient son propre fichier web.config pour lequel les erreurs personnalisées sont activées. Par conséquent, lors de la création de pages d’applications personnalisées ou du dépannage des pages d’applications SharePoint 2010, il peut être préférable de modifier le fichier web.config stocké dans le dossier {SharePoint Root}\TEMPLATE\LAYOUTS ou d’ajouter un fichier web.config personnalisé qui désactive les erreurs personnalisées dans le dossier contenant les pages d’applications personnalisées.

Pages d’applications SharePoint personnalisées

SharePoint 2010 inclut de nombreuses pages d’applications système pour des éléments tels que le signalement d’erreurs ou les notifications de refus d’accès, ainsi que des pages d’ouverture et de fermeture de session. Dans les versions antérieures de SharePoint, ces fichiers étaient codés en dur. Même si certaines d’entre elles étaient faciles à modifier (la page d’ouverture de session, par exemple, pouvait être modifiée dans le fichier web.config), d’autres ne pouvaient pas être modifiées sans rédiger une certaine quantité de code très créatif.

Microsoft a apporté des améliorations à cet aspect dans SharePoint 2010 en permettant aux développeurs d’extraire l’URL d’une page personnalisée et de créer leurs propres pages d’applications système. Cela leur permet de créer des pages d’applications système personnalisées comportant une logique métier personnalisée ou harmonisées avec le reste du site. Ces modifications peuvent être apportées à une application Web grâce à deux méthodes : GetMappedPage et UpdateMappedPage. Une liste des pages d’applications système disponibles pouvant être modifiées se trouve dans l’énumération SPWebApplication.SPCustomPage.

La modification d’une page maître système s’implémente de préférence dans les événements activés et désactivés d’une fonctionnalité à l’échelle de l’application Web. Tout d’abord, créez une page d’application qui servira de page d’application système personnalisée. Ensuite, créez une fonctionnalité d’application Web et implémentez les événements activés et désactivés, comme indiqué dans l’exemple suivant.

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;
    }
  }
}

Tableau de bord du développeur SharePoint 2010

Le Tableau de bord du développeur est une autre nouveauté de SharePoint 2010 destinée à aider les développeurs lors de la journalisation et du débogage des composants personnalisés ajoutés à des pages SharePoint. Il peut être activé pour une batterie entière afin d’obtenir un instantané de l’activité et des performances d’une demande de page spécifique.

Figure 1. Tableau de bord du développeur

Tableau de bord du développeur

Le Tableau de bord du développeur peut être très utile lors du dépannage des composants à problème sur une page, car une page SharePoint peut contenir plusieurs composants personnalisés. Lorsque c’est le cas et que les performances de la page en termes de rapidité sont au-dessous des attentes, il peut être difficile d’isoler le composant à la base du problème autrement que par simple processus d’élimination. Il s’agit précisément du scénario dans lequel le Tableau de bord du développeur peut se révéler d’une aide précieuse.

Le Tableau de bord du développeur comporte différentes catégories d’informations. Il fournit des détails sur la durée nécessaire au traitement des threads, sur la quantité et durée d’exécution des appels de base de données SQL Server et des appels de service WCF (Windows Communication Foundation), des détails sur l’URL, sur l’utilisateur actuel, et ainsi de suite.

Configuration du Tableau de bord du développeur

Par défaut, le Tableau de bord du développeur n’est pas activé. Son activation peut s’effectuer par le biais de l’API ou d’un script Windows PowerShell personnalisé, comme indiqué dans l’exemple suivant.

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

Deux niveaux d’affichage différents sont disponibles sur le Tableau de bord du développeur. L’option d’énumération SPDeveloperDashboardLevel.On active le tableau de bord sur toutes les pages d’une batterie. L’option SPDeveloperDashboardLevel.OnDemand désactive le tableau de bord, mais ajoute une image semblable à un compteur de performance dans le coin supérieur droit de la page. Lorsque vous cliquez sur cette image, une publication (postback) est déclenchée et le Tableau de bord du développeur est ajouté à la page.

Pour plus d’informations sur le Tableau de bord du développeur, voir Utilisation du tableau de bord du développeur dans le kit SDK SharePoint 2010.

Bien que le Tableau de bord du développeur contienne une quantité considérable d’informations relatives aux processus SharePoint, les développeurs peuvent également ajouter leur propre journalisation dans des composants personnalisés qui s’affichent dans le tableau de bord.

Écriture dans le Tableau de bord du développeur

L’écriture dans le Tableau de bord du développeur peut s’effectuer directement à partir de solutions de batterie uniquement ; les solutions en bac à sable (sandbox) ne peuvent pas écrire dans le Tableau de bord du développeur car elles sont isolées dans le processus de code utilisateur. Pour permettre l’écriture dans le Tableau de bord du développeur, un composant personnalisé doit être enveloppé dans un objet SPMonitoredScope.

Le code suivant montre comment écrire dans le Tableau de bord du développeur et comment créer des étendues imbriquées.

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);
    }
  }
}

La Figure 2 illustre les conséquences de l’ajout, sur la page, du composant WebPart contenu dans l’exemple de code précédent.

Figure 2. Écriture dans le Tableau de bord du développeur

Écrire dans le tableau de bord du développeur

Ajout du Tableau de bord du développeur à des pages maîtres personnalisées

Le Tableau de bord du développeur est inclus dans tous les sites SharePoint qui utilisent l’une des pages maîtres fournies avec SharePoint 2010. Lors de la création de pages maîtres personnalisées, les développeurs peuvent ajouter le Tableau de bord du développeur en ajoutant simplement le contrôle serveur suivant, de préférence au bas de la page :

<SharePoint:DeveloperDashboard runat="server" />

Lorsque le Tableau de bord du développeur est configuré avec l’option SPDeveloperDashboardLevel.OnDemand, il utilise le lanceur de tableau de bord pour afficher l’icône et le tableau de bord. Il convient d’ajouter également le contrôle suivant aux pages maîtres personnalisées :

<SharePoint:DeveloperDashboardLauncher runat="server" />

Ce contrôle contient quelques propriétés publiques permettant de modifier le placement, le texte et l’image utilisée pour afficher le contrôle. Ces propriétés se trouvent dans la classe DeveloperDashboardLauncher dans le kit SDK SharePoint 2010.

Conclusion

Microsoft a mis en œuvre dans la dernière version de SharePoint, Microsoft SharePoint 2010, de nombreuses améliorations destinées aux développeurs. Au-delà des excellents outils de développement fournis avec Visual Studio 2010, Microsoft a ajouté de précieuses fonctionnalités et une certaine flexibilité permettant aux développeurs d’ajouter des techniques de journalisation et de débogage aux solutions personnalisées créées pour SharePoint 2010. Cet article décrit certaines techniques de journalisation et de débogage courantes désormais accessibles aux développeurs lors de la création d’applications SharePoint 2010.

Ressources supplémentaires

Pour plus d’informations, voir les ressources suivantes :