Bereitstellen von Features

Bereitstellen von Lösungspaketen (SharePoint Foundation 2010)

Veröffentlicht: 12. Mai 2010

In diesem Artikel werden Lösungspakete und ihre Rolle bei der Bereitstellung von erstellten und entwickelten Anpassungen in Microsoft SharePoint Foundation 2010 beschrieben. Er enthält Verfahren zum Importieren und Bereitstellen von Lösungspaketen sowie ein Beispiel für das Erstellen und Bereitstellen eines Lösungspakete mit Microsoft Visual Studio 2010.

Inhalt dieses Artikels:

• Was ist ein Lösungspaket?
  
• Bereitstellen von Websiteelementen mithilfe von Lösungspaketen
  
• Erstellen und Bereitstellen eines benutzerdefinierten Webpartlösungspakets mithilfe von Visual Studio 2010
  

Was ist ein Lösungspaket?

Ein Lösungspaket ist ein Verteilungspaket, mit dem ein benutzerdefiniertes SharePoint Foundation 2010-Entwicklungsergebnis auf den Webservern oder Anwendungsservern in der Serverfarm bereitgestellt wird. Verwenden Sie Lösungen, um benutzerdefinierte Features, Websitedefinitionen, Vorlagen, Layoutseiten, Webparts, Cascading Stylesheets und Assemblys zu packen und bereitzustellen.

In diesem Artikel wird nicht die Bereitstellung von Sandkastenlösungen erläutert. Sie können eine Microsoft SharePoint Foundation 2010-Lösung direkt in der SharePoint Foundation-Farm bereitstellen, oder Sie können die Lösung in einem Sandkasten bereitstellen. Ein Sandkasten ist eine eingeschränkte Ausführungsumgebung, in der Programme nur auf bestimmte Ressourcen zugreifen können. Im Sandkasten auftretende Probleme können sich nicht auf die übrige Serverumgebung auswirken. Weitere Informationen finden Sie unter Übersicht über Sandkastenlösungen (SharePoint Foundation 2010).

Ein Lösungspaket ist eine CAB-Datei mit der Dateinamenerweiterung WSP und einer Manifestdatei. Zum Entwickeln und Packen von SharePoint-Lösungen wird die Verwendung der Visual Studio 2010-Tools für SharePoint 2010 empfohlen. Lösungspakete können auch manuell mit Tools wie Makecab.exe und SharePoint Packman erstellt werden.

Die folgenden Komponenten können u. a. in einem Lösungspaket gepackt werden:

• .NET Framework-Assemblys, i. d. R. Webpartassemblys und Ereignisempfängerassemblys.
  
• Bereitstellungsdateien, z. B. Ressourcendateien, Seiten oder andere Hilfsdateien.
  
• Features, die Ihnen das Aktivieren und Deaktivieren von Code in einer Website und das Bereitstellen von Funktionen ermöglichen, die Elemente, z. B. benutzerdefinierte Listen, Bibliotheken, Felder und Inhaltstypen, umfassen.
  
• Neue Vorlagen und Websitedefinitionen.
  
• Konfigurationen, die auf Webserverebene vorgenommen werden müssen, beispielsweise das Bereitstellen von Anpassungen der Datei Web.config für die Registrierung von Webparts. Sie können diese Konfigurationen auch mit einem Feature ändern, das mit einem Feature verteilt wird.
  
• Webinhalt, z. B. Webseiten und Bilder, die von Webseiten aufgerufen werden. Wenn Sie Webinhalt in einer getrennten Umgebung bereitstellen müssen, sollten Sie ein Inhaltsbereitstellungspaket verwenden.
  

Bereitstellen von Websiteelementen mithilfe von Lösungspaketen

Inhalt dieses Abschnitts:

• Verwendung von Lösungspaketen
  
• Bereitstellen von Farmlösungen
  
• Hinzufügen eines Lösungspakets
  
• Bereitstellen eines Lösungspakets
  
• Informationen zum Erstellen eines Lösungspakets
  

Verwendung von Lösungspaketen

Ein empfohlenes Verfahren zum Bereitstellen von Anpassungen ist die Verwendung von Lösungspaketen als Teil einer einfachen, sicheren und einheitlichen Anwendungslebenszyklusverwaltung. Lösungspakete vereinfachen das Ändern von Features und Funktionen der Websites, nachdem sie erstellt wurden.

Sie können Lösungspakete zum Bereitstellen neuer Lösungen und zum Upgraden vorhandener Lösungen in der gesamten Farm verwenden. Sie können alle SharePoint Foundation-Entitäten als eine Datei packen, die Datei dem Lösungsspeicher hinzufügen und sie auf den Front-End-Webservern in der Farm bereitstellen. Verwenden Sie Lösungspakete zum Synchronisieren eines Front-End-Webservers, damit sein Zustand mit dem Zustand anderer Webserver in der Farm konsistent ist.

Mit Lösungspaketen können erstellte Websiteelementanpassungen aus einer Integrationsfarm in einer Erstellungs-, Pilot- und Produktionsfarm bereitgestellt werden. In SharePoint Foundation können Benutzer eine angepasste Website als Vorlage speichern. Dadurch wird ein Lösungspaket mit der Dateinamenerweiterung WSP erstellt, das in einer anderen Farm bereitgestellt werden kann.

Mit Lösungspaketen können Sie Anpassungen zwischen den folgenden Umgebungen bereitstellen:

• Von Entwicklerarbeitsstationen in einer Integrationsfarm oder einem Softwarekonfigurations-Verwaltungssystem
  
• Von einer Integrationsfarm und Clientarbeitsstationen für die Erstellung in Pilot- oder Produktionsfarmen
  

Bereitstellen von Farmlösungen

Farmlösungen werden lokal oder mit einem Timerdienst bereitgestellt. Lokale und timerbasierte Bereitstellungen können mit Befehlszeilenanweisungen oder programmgesteuert mithilfe des Objektmodells ausgelöst werden.

Lokale Bereitstellung

Bei einer lokalen Bereitstellung werden Lösungsdateien nur auf dem Computer bereitgestellt, von dem die Bereitstellung initiiert wurde. Die Lösung wird in der Konfigurationsdatenbank erst als bereitgestellt markiert, wenn die Lösungsdateien auf allen entsprechenden Servern in der Serverfarm bereitgestellt sind. Anschließend werden Lösungsfeatures installiert, und es wird ein Commit von Schema- sowie Definitionsdateien für den Konfigurationsspeicher ausgeführt.

Timerdienstbereitstellungen

Wenn in Bereitstellungen der Timerdienst verwendet wird, wird durch die Bereitstellung ein Zeitgeberauftrag erstellt. Der Zeitgeberauftrag wird vom Timerdienst auf jedem Webserver in der Serverfarm ausgewählt. Zunächst werden das Manifest und Featuremanifeste analysiert, um Assembly- und Layoutdateien zu ermitteln, die an die entsprechenden Speicherorte kopiert werden. Alle anderen Dateien in einem Featureverzeichnis werden in das Featureverzeichnis kopiert. Nachdem Lösungsdateien auf die Zielcomputer kopiert wurden, wird für alle Front-End-Webserver das Zurücksetzen der Konfiguration geplant. Durch das Zurücksetzen werden dann die Dateien bereitgestellt und ein Neustart von Microsoft Internetinformationsdienste (IIS) ausgeführt. Anschließend werden Lösungsfeatures registriert, und es wird ein Commit von Schema- und Definitionsdateien für den Konfigurationsspeicher ausgeführt.

Weitere Informationen zum Lösungsspeicher, zur Bereitstellung und zur Synchronisierung finden Sie im Microsoft SharePoint 2010 Software Development Kit (SDK) unter Bereitstellen einer Lösung (http://go.microsoft.com/fwlink/?linkid=186995&clcid=0x407).

Hinzufügen eines Lösungspakets

Bevor Sie ein Lösungspaket bereitstellen können, müssen Sie es der Lösungsdatenbank einer SharePoint Foundation-Farm hinzufügen.

Wichtig:
Sie müssen Mitglied der Gruppe Administratoren auf jedem Computer sein, auf dem Windows PowerShell ausgeführt wird.

So importieren Sie ein Lösungspaket mit Windows PowerShell

1. Stellen Sie sicher, dass die folgenden Mindestanforderungen erfüllt sind: Weitere Informationen finden Sie unter Add-SPShellAdmin.
2. Klicken Sie im Startmenüauf Alle Programme.
3. Klicken Sie auf Microsoft SharePoint 2010-Produkte.
4. Klicken Sie auf SharePoint 2010-Verwaltungsshell.
5. Geben Sie an der Windows PowerShell-Eingabeaufforderung den folgenden Befehl ein:
   Add-SPSolution -LiteralPath <SolutionPath>

Die Lösung wird dem Lösungsspeicher der Farm hinzugefügt. Befolgen Sie zum Verwenden der Lösung das Verfahren im nächsten Abschnitt dieses Artikels. Weitere Informationen finden Sie unter Add-SPSolution.

Bereitstellen eines Lösungspakets

Sie können importierte Lösungen mit der Website für die Zentraladministration oder mit Windows PowerShell bereitstellen. Nachdem eine Lösung mit demWindows PowerShellAdd-SPSolution-Cmdlet dem Lösungsspeicher hinzugefügt wurde, muss sie auf einer Website bereitgestellt werden, bevor auf sie zugegriffen werden kann.

Hinweis:
Lösungen können dem Lösungsspeicher nicht mithilfe der Seite Lösungsverwaltung der Zentraladministration hinzugefügt werden.

Im folgenden Verfahren wird das Bereitstellen einer importierten Lösung auf einer Website in der Farm mit der Website für die Zentraladministration oder mithilfe von Windows PowerShell veranschaulicht.

So stellen Sie eine Lösung mithilfe der Zentraladministration bereit

1. Klicken Sie auf der Homepage der Zentraladministration auf Systemeinstellungen.
2. Klicken Sie im Abschnitt Farmverwaltung auf Farmlösungen verwalten.
3. Klicken Sie auf der Seite Lösungsverwaltung auf die Lösung, die Sie bereitstellen möchten.
4. Klicken Sie auf der Seite Eigenschaften der Lösung auf Lösung bereitstellen.
5. Wählen Sie auf der Seite Lösung bereitstellen im Abschnitt Zeitpunkt der Bereitstellung eine der folgenden Optionen aus:
   • Jetzt
     
   • Zur angegebenen Zeit. Wenn Sie diese Option auswählen, müssen Sie mithilfe der Datums- und Uhrzeitfelder eine Zeit angeben. Es ist empfehlenswert, eine Zeit mit geringer Auslastung des Zielservers auszuwählen.
     
6. Klicken Sie im Abschnitt Bereitstellen für in der Liste Bestimmte Webanwendung auf Alle Webanwendungen, oder wählen Sie eine bestimmte Webanwendung aus.
7. Klicken Sie auf OK.

So stellen Sie ein Lösungspaket mithilfe von Windows PowerShell für eine einzelne Webanwendung bereit

1. Stellen Sie sicher, dass die folgenden Mindestanforderungen erfüllt sind: Weitere Informationen finden Sie unter Add-SPShellAdmin.
2. Klicken Sie im Startmenüauf Alle Programme.
3. Klicken Sie auf Microsoft SharePoint 2010-Produkte.
4. Klicken Sie auf SharePoint 2010-Verwaltungsshell.
5. Geben Sie an der Windows PowerShell-Eingabeaufforderung den folgenden Befehl ein:
   Install-SPSolution -Identity <SolutionName> -WebApplication <URLname>

   Dabei gilt Folgendes:
   • <SolutionName> ist der Name der Lösung.
     
   • <URLname> ist die URL der Webanwendung, für die Sie die importierte Lösung bereitstellen möchten.
     
   Standardmäßig wird die Lösung sofort bereitgestellt. Sie können auch mit dem time-Parameter die Bereitstellung planen. Weitere Informationen finden Sie unter Install-SPSolution.

So stellen Sie ein Lösungspaket mithilfe von Windows PowerShell für alle Webanwendungen bereit

1. Stellen Sie sicher, dass die folgenden Mindestanforderungen erfüllt sind: Weitere Informationen finden Sie unter Add-SPShellAdmin.
2. Klicken Sie im Startmenüauf Alle Programme.
3. Klicken Sie auf Microsoft SharePoint 2010-Produkte.
4. Klicken Sie auf SharePoint 2010-Verwaltungsshell.
5. Geben Sie an der Windows PowerShell-Eingabeaufforderung den folgenden Befehl ein:
   Install-SPSolution -Identity <SolutionName> -AllWebApplications -time <TimeToDeploy> -GACDeployment -CASPolicies

   Dabei gilt Folgendes:
   • GACDeployment ist der Parameter, der das Bereitstellen der Assemblys im globalen Assemblycache durch SharePoint Foundation 2010 ermöglicht.
     
   • CASPolicies ermöglicht die Erstellung einer benutzerdefinierten Richtliniendatei für die Codezugriffsicherheit (Code Access Security, CAS) und die Aktivierung in der Datei Web.config der betreffenden Websitesammlung.
     
   Standardmäßig wird die Lösung sofort bereitgestellt. Sie können die Bereitstellung auch mithilfe des time-Parameters planen.

Informationen zum Erstellen eines Lösungspakets

SharePoint Foundation 2010 enthält kein Tool zum Erstellen von Lösungspaketen. In diesem Abschnitt werden Verfahren zum Erstellen von Lösungspaketen, die entwickelte Websiteelemente und Artefakte enthalten, beschrieben.

Visual Studio 2010

Mit Visual Studio 2010 können Sie verwandte SharePoint-Elemente in einem Feature zusammenfassen und dann mehrere Features, Websitedefinitionen, Assemblys und andere Dateien in einem einzelnen Paket (WSP-Datei) zur Bereitstellung auf Servern mit SharePoint Foundation 2010 bündeln. Sie können Visual Studio 2010 zum Debuggen und Testen der WSP-Datei auf dem Server mit SharePoint Foundation 2010. Sie können auch die Bereitstellungsschritte auf dem Entwicklungscomputer anpassen.

Entwickler können mit dem automatisierten Buildprozess SharePoint-Lösungen in Visual Studio 2010 erstellen und WSP-Dateien erzeugen. Quellcode des Visual Studio-SharePoint-Projekts, mit dem die WSP-Datei generiert wird, kann dem Quellcodeverwaltungssystem mithilfe der Visual Studio 2010-Integration hinzugefügt werden. In Visual Studio 2010 können WSP-Dateien importiert und Projekte zum Erweitern der WSP-Dateien sowie zum Erstellen neuer WSP-Dateien erstellt werden. Die primäre Quelle von WSP-Dateien, die in Visual Studio 2010 importiert werden, sind Vorlagen, die auf SharePoint Foundation 2010-Websites mit dem Befehl Als Vorlage speichern von Websites gespeichert wurden. Mit diesen Vorlagen können alle Websiteanpassungen einer SharePoint-Lösung gespeichert werden.

Weitere Informationen finden Sie unter SharePoint-Entwicklung in Visual Studio (http://go.microsoft.com/fwlink/?linkid=187000&clcid=0x407).

Makecab

Lösungspakete können mit Tools, z. B. Makecab.exe, manuell erstellt werden. Das Tool Makecab.exe akzeptiert einen Zeiger auf eine DDF-Datei, die die Struktur der CAB-Datei beschreibt. Das Format einer DDF-Datei ähnelt dem Format einer INF-Datei: Sie deklarieren einen Standardheader und listen dann den Satz der Dateien nach ihrem Speicherort auf dem Datenträger und ihrem vorgesehenen Speicherort in der CAB-Datei auf, wobei pro Zeile eine Datei aufgelistet wird.

Das Tool Makecab.exe kann unter Microsoft Cabinet Software Development Kit (http://go.microsoft.com/fwlink/?linkid=107292&clcid=0x407) heruntergeladen werden.

Informationen zum Anpassen von Lösungspaketen

Wenn Sie in SharePoint Foundation 2010-Lösungen eine der folgenden Anpassungen vornehmen müssen, wird empfohlen, zum Anpassen von Lösungspaketen Visual Studio 2010 zu verwenden. Sie können diese Anpassungen auch durch das manuelle Erstellen von SharePoint-Lösungspaketen ausführen.

• Stellen Sie .NET Framework-Assemblys im privaten Anwendungsordner statt im globalen Assemblycache bereit.
  
• Fügen Sie der Lösung, die während der Bereitstellung angewendet werden muss, Berechtigungen für die Codezugriffssicherheit hinzu.
  
• Verwenden Sie für die Featureordner andere Namen als die Standardnamen.
  
• Lokalisieren Sie die Lösung.
  
• Ordnen Sie bestimmten Typen von SharePoint Foundation 2010-Lösungen, z. B. Webpartlösungen, Featureereignishandler zu.
  
• Fügen Sie dem Lösungspaket Ressourcen (XML-Dateien, Bilder, DLL-Dateien und Assemblys) hinzu.
  

Manuelles Erstellen einer Lösungsdatei

Für die meisten SharePoint Foundation 2010-Bereitstellungsszenarien wird empfohlen, zum Entwickeln und Packen von SharePoint-Lösungen Visual Studio 2010-Tools für SharePoint 2010 zu verwenden. In Visual Studio 2010 wird bei der Bereitstellung die WSP-Datei auf den Server mit SharePoint Foundation 2010 kopiert, die Lösung wird installiert, und dann werden die Features aktiviert.

Sie können auch eine Lösungsdatei manuell erstellen. Nachfolgend werden die grundlegenden Schritte zum Erstellen einer Lösungsdatei beschrieben:

1. Sammeln Sie alle einzelnen Lösungsdateien in einem Ordner. Es gibt keine konkreten Richtlinien dazu, wie Sie vorgehen sollten, aber eine bewährte Methode besteht darin, die verschiedenen Typen von Lösungsdateien in einem eigenen Unterordner zu speichern.
   
2. Erstellen Sie die Datei manifest.xml, in der die Komponenten der Lösung aufgeführt werden.
   
3. Erstellen Sie eine DDF-Datei, mit der die Struktur der Lösungsdatei definiert wird. Diese Datei enthält die Liste der einzelnen Lösungsdateien, mit denen die WSP-Ausgabedatei bestimmt wird.
   
4. Führen Sie Makecab.exe mit der DDF-Datei als Eingabe und der WSP-Datei als Ausgabe aus.
   

Informationen über die Lösungsmanifestdatei

Das Lösungsmanifest (immer als manifest.xml bezeichnet) wird am Stamm einer Lösungsdatei gespeichert. Diese Datei definiert die Liste der zu verarbeitenden Features, Websitedefinitionen, Ressourcendateien, Webpartdateien und Assemblys. Sie definiert nicht die Dateistruktur. Wenn Dateien in einer Lösung enthalten sind, jedoch nicht in der Datei manifest.xml aufgeführt sind, werden sie nicht verarbeitet.

Im folgenden Beispiel wird die Struktur der Datei manifest.xml in XML dargestellt.

<?xml version="1.0" encoding="utf-8" ?>

<Solution xmlns="http://schemas.microsoft.com/sharepoint/"

SolutionId="{79d1a62e-3627-11db-963e-00e08161165f}"

ResetWebServer="TRUE">

    <Assemblies>

        <Assembly DeploymentTarget="GlobalAssemblyCache"

Location="Example.Sharepoint.Webparts\

Example.SharePoint.WebParts.dll">

            <SafeControls>

                <SafeControl Assembly="Example.Sharepoint.Webparts,

Version=1.0.0.0, Culture=Neutral, PublicKeyToken=63cce650e8605f5d"

Namespace="Example.Sharepoint.Webparts" TypeName="*"/>

            </SafeControls>

        </Assembly>

        <Assembly DeploymentTarget="GlobalAssemblyCache"

Location="Example.Sharepoint.Timer/Example.Sharepoint.Timer.dll"/>

    </Assemblies>

    <FeatureManifests>

        <FeatureManifest Location="Example.Sharepoint.Timer\Feature.xml"/>

        <FeatureManifest Location="Example.CustomType\Feature.xml"/>

        <FeatureManifest Location="Example.ExampleLibrary\Feature.xml"/>

        <FeatureManifest Location="Example.Columns\Feature.xml"/>

        <FeatureManifest Location="Example.Workflow.ProcessExample\Feature.xml"/>

        <FeatureManifest Location="Example.Workflow.ProvisionExample\Feature.xml"/>

    </FeatureManifests>

    <SiteDefinitionManifests>

        <SiteDefinitionManifest Location="EXAMPLE">

            <WebTempFile Location="1033\XML\WEBTEMPExample.XML"/>

        </SiteDefinitionManifest>

    </SiteDefinitionManifests>

</Solution>

Darüber hinaus können Sie ein DwpFiles-Element zum Angeben von WEBPART- oder DWP-Dateien oder ein ResourceFiles-Element zum Angeben von Ressourcendateien, Websitedefinitionen, Anwendungsressourcen und Richtlinien für die Codezugriffssicherheit hinzufügen.

Optional können Sie die Datei Feature.xml mit <ElementFile>-Tags kommentieren.

Wenn die Lösung Features enthält, fügen Sie im <ElementManifests>-Tag der Datei Feature.xml<ElementFile Location="..."/> für alle zusätzlichen Dateien im Feature, z. B. ASP.NET-Seiten (wie allitems.aspx) oder Gestaltungsvorlagen usw., hinzu.

Weitere Informationen zu Lösungsmanifestdateien, die wesentliche Bestandteile einer Lösung definieren, finden Sie unter Lösungsschema(http://go.microsoft.com/fwlink/?linkid=183466&clcid=0x407).

Erstellen und Bereitstellen eines benutzerdefinierten Webpartlösungspakets mithilfe von Visual Studio 2010

Eine exemplarische Vorgehensweise, in der die Verwendung von Visual Studio 2010 zum Erstellen, Anpassen, Debuggen und Bereitstellen einer SharePoint-Listendefinition zum Nachverfolgen von Projektaufgaben veranschaulicht wird, finden Sie unter Exemplarische Vorgehensweise: Bereitstellen einer Aufgabenlistendefinition für Projekte (http://go.microsoft.com/fwlink/?linkid=189612&clcid=0x407) in der MSDN Library.

In dieser exemplarischen Vorgehensweise werden die folgenden Aufgaben veranschaulicht:

• Erstellen eines SharePoint-Listendefinitionsprojekts, das Aufgaben enthält
  
• Hinzufügen von Listendefinitionen zu einem SharePoint-Feature
  
• Hinzufügen eines Ereignisempfängers zur Liste
  
• Erstellen und Anpassen eines SharePoint-Pakets zum Bereitstellen des Features
  
• Erstellen und Bereitstellen der SharePoint-Lösung
  

Wenn Sie das Beispielprojekt in dieser exemplarischen Vorgehensweise erstellen, wird die Lösung von Visual Studio 2010 automatisch dem Server hinzugefügt, der SharePoint Foundation 2010 auf dem Entwicklungscomputer zum Testen und Debuggen ausführt. Sie können auch eine Lösungspaketdatei erstellen, die Sie hinzufügen und auf einem anderen Computer bereitstellen können. Weitere Informationen finden Sie unter Gewusst wie: Bereitstellen einer SharePoint-Lösung(http://go.microsoft.com/fwlink/?linkid=187004&clcid=0x407). Sie können die Lösung mit dem Add-SPSolutionWindows PowerShell-Cmdlet auf einen anderen Computer importieren.

Sie können das Lösungspaket mit der Seite Lösungsverwaltung in der Zentraladministration bereitstellen. Alternativ können Sie das Lösungspaket mit demInstall-SPSolutionWindows PowerShell-Cmdlet bereitstellen.

Der Bereich des Projektlistenfeatures in der exemplarischen Vorgehensweise ist Web. Gehen Sie zum Aktivieren des Features wie folgt vor: Erweitern Sie auf der Website das MenüWebsiteaktionen, und klicken Sie dann auf Websiteeinstellungen. Klicken Sie unter Websiteaktionenauf Websitefeatures verwalten. Klicken Sie auf der Seite Features neben dem Featurenamen auf Aktivieren.

Änderungsverlauf

Datum	Beschreibung	Grund
12. Mai 2010	Erstveröffentlichung

Verwalten Sie Ihr Profil | Impressum | Kontaktieren Sie uns | Newsletter © 2011 Microsoft. Alle Rechte vorbehalten. Nutzungsbedingungen | Markenzeichen | Informationen zur Datensicherheit

Features pour SharePoint, c´est quoi ?

Office Space

Fonctionnalités pour SharePoint

Ted Pattison

Téléchargement du code disponible sur: OfficeSpaceFeature2007_05.exe (190 KB) 
Browse the Code Online

  Sommaire

Qu'est-ce qu'une « fonctionnalité » ?
Structure d'une fonctionnalité
Déploiement et activation de la fonctionnalité
Extension de la fonctionnalité
Pages d'application personnalisées
Résumé 

Dans mon précédent article Office Space, j'ai abordé les formats de fichier XML ouvert Office. En particulier, j'ai expliqué comment écrire le code sous-jacent d'une page ASP.NET pour produire un fichier .docx pour Microsoft® Word à l'aide de l'API d'empaquetage fournie par Microsoft .NET Framework 3.0. Dans l'édition de ce mois, je m'appuie sur ce que j'ai déjà présenté au sujet des formats de fichier XML ouvert Office. Je cherche à intégrer ce code dans une solution d'entreprise qui peut être déployée dans Windows® Sharepoint® Services (WSS) 3.0 ou Microsoft Office SharePoint Server (MOSS) 2007.

L'intérêt de l'article Office Space du mois est de présenter les composants fondamentaux utilisés pour créer des solutions métier avec WSS et MOSS. J'y explique ce qu'est une « fonctionnalité » WSS et indique comment générer une fonctionnalité qui automatise la création de listes et de bibliothèques de documents sur un site. Dans le cadre de cette explication, j'ajoute une page d'application personnalisée à la solution métier personnalisée. Elle contient le code Visual Basic® nécessaire à la génération de documents Word à partir de données qui se trouvent dans des listes Sharepoint et à l'enregistrement de ces documents dans une bibliothèque de documents Sharepoint.

Qu'est-ce qu'une « fonctionnalité » ?

Lors du développement de solutions d'entreprise personnalisées pour WSS et MOSS, vous devez d'abord bien comprendre les fonctionnalités (et je ne fais pas référence au jeu de fonctionnalités dans son ensemble). Les fonctionnalités constituent une nouvelle innovation axée sur les développeurs, qui a été ajoutée à WSS 3.0. Fondamentalement, elles offrent un mécanisme de définition des éléments d'un site, lequel peut être activé automatiquement dans le contexte d'un site cible ou d'une collection de sites cible. Les types d'élément pouvant être définis par une fonctionnalité sont les instances de liste, les types de liste, les commandes de menu, les modèles de page, les instances de page, les gestionnaires d'événements et les flux de travail. L'exemple sur lequel je m'appuie dans cet article utilise une fonctionnalité appelée OfficeSpaceFeature, qui crée une liste et une bibliothèque de documents, et ajoute une option de menu personnalisée au menu Actions du site standard de WSS, ce qui permet à l'utilisateur d'accéder à une page d'application personnalisée.

Une fonctionnalité comporte un répertoire créé dans un répertoire système WSS spécial situé dans le système de fichiers de chaque serveur Web frontal. Le répertoire d'une fonctionnalité contient un ou plusieurs fichiers XML, qui contiennent des données CAML (automatiquement). Par convention, chaque répertoire de fonctionnalité contient un fichier de manifeste appelé feature.xml. Ce fichier définit les attributs de haut niveau de la fonctionnalité, tels que son identifiant et son titre convivial.

Outre le fichier feature.xml, une fonctionnalité contient généralement un ou plusieurs fichiers XML supplémentaires (elements.xml, par exemple), qui définissent les éléments réels qui composent la fonctionnalité. Le répertoire peut également contenir d'autres types de fichiers pour des choses comme les définitions de liste et modèles de pages et des ressources comme les images, les feuilles de style en cascade et Javascript. Le répertoire de fonctionnalité de mon exemple inclut un fichier supplémentaire, qui sert de modèle de document pour une bibliothèque de documents.

Pour connaître rapidement les fonctionnalités, examinez le jeu de fonctionnalités standard inclus avec l'installation WSS de base. La figure 1 illustre l'apparence d'un exemple de répertoire FEATURES une fois que WSS est installé. Comme vous pouvez le constater, chaque fonctionnalité possède son propre répertoire. Le répertoire FEATURES se présente différemment si MOSS est installé car celui-ci inclut plus de 100 fonctionnalités.

Figure 1 Répertoire FEATURES standard (Cliquer sur l'image pour l'agrandir)

Une fois que vous avez créé le répertoire avec tous les fichiers composant la fonctionnalité, vous devez ensuite l'installer avec WSS à l'échelle de la batterie de serveurs. Lorsqu'une fonctionnalité a été installée avec WSS, elle peut être activée dans le contexte d'un site ou d'une collection de sites à l'aide d'un page d'administration accessible via la page Paramètres du site.

Les éléments à télécharger pour cet article incluent un projet Visual Studio® appelé OfficeSpaceFeature, qui comporte une fonctionnalité du même nom. La figure 2 présente une vue de l'Explorateur de solutions pour vous donner une idée des types de fichier impliqués lorsque vous créez un projet Visual Studio afin de développer une fonctionnalité personnalisée pour WSS ou MOSS. J'ai créé l'exemple de cet article sous forme de projet de DLL Visual Basic. Vous pouvez, bien entendu, utiliser un projet de DLL C# à la place si vous préférez. Le code géré dans la DLL de l'assembly doit être compilé avec un nom fort et installé dans le Global Assembly Cache (GAC) pour pouvoir être utilisé pour les gestionnaires d'événements de la fonctionnalité.

Figure 2 OfficeSpaceFeature 

Structure d'une fonctionnalité

Avant d'examiner le fichier feature.xml, rappelez-vous que les fichiers de cette fonctionnalité doivent être déployés dans leur propre répertoire à l'intérieur du répertoire système WSS appelé FEATURES. Le répertoire FEATURES se trouve dans un autre répertoire système WSS, appelé TEMPLATE, comme illustré à la figure 1. Compte tenu des exigences de déploiement de la fonctionnalité, il convient de créer une hiérarchie parallèle de dossiers dans un projet Visual Studio utilisé pour développer une fonctionnalité WSS. Cela facilite la copie des fichiers de la fonctionnalité dans l'emplacement approprié et leur test dans le cadre de votre travail de développement.

Commencez par ajouter un dossier appelé TEMPLATE dans le répertoire principal du projet actuel. Ensuite, créez un autre répertoire dans le répertoire TEMPLATE, appelé FEATURES. Enfin, créez un autre répertoire dans le répertoire FEATURES en utilisant le nom du projet de fonctionnalité. Dans le cas présent, le nom du projet et du répertoire est OfficeSpaceFeature, comme vous pouvez le constater à lafigure 2.

Passons maintenant au contenu CAML du fichier feature.xml. Le fichier feature.xml sert de manifeste de fonctionnalité dans lequel vous spécifiez les informations qui définissent les attributs de haut niveau de la fonctionnalité proprement dite. Le fichier feature.xml de mon exemple de fonctionnalité se présente comme illustré à la figure 3.

  Figure 3 Exemple de fichier Feature.xml

<?xml version=”1.0” encoding=”utf-8” ?>

<Feature Id=”AAEC2E08-1CCF-4712-AE5E-A33BEA53A325” 
  Title=”A Sample Office Space Feature”
  Description=
    “Demoware from Ted Pattison’s Office Space column in MSDN Magazine”
  Version=”1.0.0.0”
  Scope=”Web”
  ImageUrl=”OfficeSpace/PithHelmet.gif”
  ReceiverAssembly=”OfficeSpaceFeature, [full strong name]”
  ReceiverClass=”OfficeSpaceFeature.FeatureReceiver”
  xmlns=”http://schemas.microsoft.com/sharepoint/”>

    <ElementManifests>
      <ElementManifest Location=”elements.xml” />
    </ElementManifests>

</Feature>

Vous pouvez constater qu'une fonctionnalité est définie à l'aide d'un élément Feature, qui contient plusieurs attributs tels que Id, Title, Description, Version, Scope, Hidden et ImageUrl. Vous devez créer un nouveau GUID pour l'attribut Id afin que votre fonctionnalité puisse être identifiée de manière unique. Vous créez les attributs Title et Description de la fonctionnalité à l'aide de texte convivial. Ces attributs apparaissent directement aux utilisateurs dans les pages d'administration WSS, qui sont utilisées pour activer et désactiver les fonctionnalités.

L'attribut Scope (Portée) définit le contexte dans lequel la fonctionnalité peut être activée et désactivée. La fonctionnalité que je crée possède une portée correspondant à Web, ce qui signifie qu'elle peut être activée et désactivée dans le contexte d'un site. Si vous affectez une valeur Site à l'attribut Scope, la fonctionnalité peut être ensuite activée et désactivée dans la portée d'une collection de sites. Les deux autres valeurs Scope possibles pour définir une fonctionnalité sont WebApplication et Farm.

Comme vous pouvez le constater, l'attribut Hidden prend la valeur FALSE. Cela signifie qu'une fois installée au sein de la batterie de serveurs, la fonctionnalité est visible par des utilisateurs qui peuvent avoir envie de l'activer. Si vous créez une fonctionnalité avec la valeur d'attribut Hidden TRUE, la fonctionnalité est masquée dans la liste de fonctionnalités disponibles affichées pour les utilisateurs. Les fonctionnalités masquées doivent être activées dans la ligne de commande, par le biais de code personnalisé ou via une dépendance d'activation avec une autre fonctionnalité.

Vous avez peut-être remarqué que l'attribut ImageUrl possède une valeur qui pointe vers une des images graphiques incluses dans l'installation WSS de base. Cette image sera affichée en regard de la fonctionnalité dans l'interface utilisateur.

La dernière partie du fichier feature.xml illustrée à la figure 3 est l'élément Element­Manifest. Cet élément contient des éléments ElementManifest internes, qui renvoient à d'autres fichiers XML dans lesquels vous définissez les éléments qui composent la fonctionnalité. Dans ce cas, il y a un seul élément ElementManifest, qui utilise l'attribut Location pour pointer vers un fichier appelé element.xml.

Notez que lorsque vous ajoutez et modifiez du code XML dans des fichiers CAML tels que feature.xml et elements.xml, vous devez ajouter la prise en charge pour IntelliSense® pour schémas XML. Dans le répertoire TEMPLATE se trouve un répertoire appelé XML qui contient plusieurs schémas XML, dont un schéma appelé wss.xsd. Si vous associez ce fichier de schéma à des fichiers de fonctionnalité tels que feature.xml et element.xml, Visual Studio met IntelliSense à disposition, ce qui facilite grandement la création de fonctionnalités personnalisées.

Il est maintenant temps d'examiner le contenu du fichier element.xml. Imaginez que vous souhaitiez instancier une bibliothèque de documents chaque fois que la fonctionnalité est activée. Vous pouvez créer un fichier elements.xml, qui se présente comme celui illustré à la figure 4.

  Figure 4 Exemple de fichier Elements.xml

<Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>

  <ListInstance
   FeatureId=”00BFEA71-E717-4E80-AA17-D0C71B360101”
   TemplateType=”101”
   Id=”CustomerLetters”
   Description=”Letters sent to customers”      
   OnQuickLaunch=”True”
   Title=”Customer Letters”    
   Url=”CustomerLetters”>
  </ListInstance>

  <Module Name=”LetterTemplate” List=”101” Url=”CustomerLetters/Forms”>
    <File Url=”LetterTemplate.docx” Type=”GhostableInLibrary” />
  </Module>

  <!-- more elements to come... -->

</Elements>

Le premier élément présenté ici, un élément ListInstance, est utilisé pour créer une instance d'une liste ou d'une bibliothèque de documents. Notez que l'élément ListInstance contient un élément FeatureId et un élément TemplateType permettant de pointer vers un type de liste spécifique et l'ID de la fonctionnalité dans laquelle ce type de liste est défini. Dans le cas présent, j'utilise le type de bibliothèque de documents WSS standard, qui possède un identifiant TemplateType de 101 pour créer une bibliothèque de documents appelée Customer Letters. Dans l'élément ListInstance, il y a également un élément Module, qui contient un élément File interne. Cet élément File est utilisé pour configurer un modèle de document pour la bibliothèque de documents. Plus précisément, cet élément File fournit à WSS des instructions pour copier un fichier appelé LetterTemplate.docs du répertoire de fonctionnalité vers le site WSS. De ce fait, il est accessible aux utilisateurs.

Bien que la logique déclarative du fichier elements.xml fournisse pratiquement tout ce dont vous avez besoin pour créer des éléments dans un site WSS, elle doit souvent être accompagnée d'une logique de programmation. Pour mon exemple, j'ai créé une bibliothèque de documents et j'ai configuré un fichier qui sert de modèle de document. Cependant, je dois fournir du code supplémentaire pour programmer dans le modèle objet WSS afin d'associer le modèle de document à la bibliothèque de documents.

Dans le fichier feature.xml, vous remarquez que l'élément Feature contient deux attributs appelés ReceiverAssembly et ReceiverClass. Ces attributs sont configurés de sorte à pointer vers une classe gérée appelée récepteur de fonctionnalité, qui fournit des gestionnaires d'événements. Les gestionnaires d'événements d'une classe de récepteur de fonctionnalité sont déclenchés lorsqu'une fonctionnalité est installée ou activée, ou lorsqu'une fonctionnalité est désinstallée ou désactivée. Vous créez un récepteur de fonctionnalité en créant une classe qui hérite de la classe SPFeatureReceiver comme illustré à lafigure 5.

  Figure 5 Classe qui hérite de SPFeatureReceiver

Imports Microsoft.SharePoint

Public Class FeatureReceiver : Inherits SPFeatureReceiver

  Public Overrides Sub FeatureActivated( _
      ByVal properties As SPFeatureReceiverProperties)
    ‘*** fires when feature is activated
  End Sub

  Public Overrides Sub FeatureDeactivating( _
      ByVal properties As SPFeatureReceiverProperties)
    ‘*** fires when feature is deactivated
  End Sub

  Public Overrides Sub FeatureInstalled( _
      ByVal properties As SPFeatureReceiverProperties)
    ‘*** fires when feature is installed
  End Sub

  Public Overrides Sub FeatureUninstalling( _
      ByVal properties As SPFeatureReceiverProperties)
    ‘*** fires when feature is uninstalled
  End Sub

End Class

Pour mon exemple, je ne fournis du code que dans le gestionnaire d'événements activé par la fonctionnalité. Ce code utilise le modèle d'objet WSS pour associer le modèle de document à la bibliothèque de documents Customer Letters. Dans le gestionnaire d'événements, cette opération est effectuée en obtenant une référence SPWeb au site actuel, puis une référence SPDocumentLibrary à la bibliothèque de documents de cible. Cela permet de modifier la propriété DocumentTemplateUrl et d'enregistrer cette modification à l'aide d'un appel de la méthode Update, comme suit :

Public Overrides Sub FeatureActivated( _
    ByVal properties As SPFeatureReceiverProperties)

  Dim site As SPWeb = CType(properties.Feature.Parent, SPWeb)

  Dim libLetterTemplates As SPDocumentLibrary 
  libLetterTemplates = CType(site.Lists(“Customer Letters”), _
    SPDocumentLibrary)
  Dim templateUrl As String = _
    “CustomerLetters/Forms/LetterTemplate.docx”
  libLetterTemplates.DocumentTemplateUrl = templateUrl
  libLetterTemplates.Update()

End Sub

Déploiement et activation de la fonctionnalité

Maintenant que j'ai créé les fichiers feature.xml et elements.xml, je souhaite installer ma fonctionnalité pour la tester. L'installation de la fonctionnalité se déroule en quatre étapes. Pour commencer, je dois installer le fichier d'assembly appelé OfficeSpaceFeature.dll dans le Global Assembly Cache. Je copie ensuite le répertoire OfficeSpaceFeature dans le répertoire système FEATURES de WSS. J'exécute alors une opération Stsadm.exe pour installer la fonctionnalité avec WSS, et pour terminer j'active la fonctionnalité dans le contexte d'un site de WSS.

Les trois premières étapes peuvent être automatisées en créant un fichier de commandes appelé install.bat dans le répertoire principal de mon projet OfficeSpaceFeature en ajoutant les instructions de ligne de commande indiquées à la figure 6. Il est également possible d'automatiser la quatrième étape en exécutant l'opération ActivateFeature avec l'utilitaire Stsadm.exe. Cependant, je n'ai pas opté pour cette possibilité dans mon exemple car je souhaite vous guider tout au long du processus d'activation manuelle de la fonctionnalité, comme le feront les utilisateurs par le biais de l'interface utilisateur WSS.

  Figure 6 Commandes d'automatisation de l'installation

@SET TEMPLATEDIR=”c:\Program Files\Common Files\Microsoft Shared\
                  web server extensions\12\TEMPLATE”
@SET STSADM=”c:\Program Files\Common Files\Microsoft Shared\
             web server extensions\12\bin\stsadm.exe”
@SET GACUTIL=”c:\Program Files\Microsoft Visual Studio 8\
              SDK\v2.0\Bin\gacutil.exe”

Echo Installing OfficeSpaceFeature.dll in GAC
%GACUTIL% -if bin\debug\OfficeSpaceFeature.dll

Echo Copying source files to WSS \TEMPLATE directory
xcopy /e /y TEMPLATE\* %TEMPLATEDIR%

Echo Installing feature with WSS
%STSADM% -o installfeature -filename  OfficeSpaceFeature\feature.xml -force

Echo Restarting IIS worker process
IISRESET

Lorsque j'ai terminé d'ajouter des instructions dans le fichier install.bat, je configure Visual Studio de sorte à l'exécuter chaque fois que je recrée le projet OfficeSpaceFeature. Je dois pour cela aller dans l'onglet Événements de génération des propriétés du projet et ajouter les instructions de ligne de commande d'événement après génération suivantes :

cd $(ProjectDir)
Install.bat

La première ligne est nécessaire pour modifier le répertoire actif afin d'utiliser le répertoire du projet. La deuxième ligne exécute le fichier de commandes pour copier les fichiers de fonctionnalité dans l'emplacement approprié et installe ensuite la fonctionnalité avec l'opération InstallFeature de l'utilitaire Stsadm.exe de ligne de commande.

Maintenant que la fonctionnalité a été correctement installée, je peux l'activer dans le contexte d'un site. Vous pouvez effectuer cette opération sur tous les sites d'une batterie de serveurs WSS ou MOSS en accédant à la page Paramètres du site. Dans la section Administration du site, cliquez sur le lien qui contient le titre Fonctionnalités du site. Vous accédez à une page comme celle illustrée à la figure 7. Si vous travaillez sur une batterie de serveurs sur laquelle MOSS est installé, vous découvrirez bien plus de fonctionnalités que si vous travaillez sur une batterie qui ne comporte que WSS.

Figure 7 Activation et désactivation des fonctionnalités du site (Cliquer sur l'image pour l'agrandir)

Le titre et la description d'OfficeSpaceFeature apparaissent dans la page Fonctionnalités du site, et sont donc faciles à trouver. Je clique sur le bouton Activer. À ce stade, tous les éléments définis avec la logique déclarative dans le fichier elements.xml doivent être configurés dans le site actuel. WSS charge alors l'assembly de récepteur du Global Assembly Cache, crée une instance de la classe de récepteur et exécute la méthode FeatureActivated de la classe de récepteur.

Mon exemple est relativement simple. Cependant, comme vous pouvez l'imaginer, vous pouvez fournir une combinaison bien plus complexe d'éléments CAML déclaratifs et de code de modèle objet WSS dans FeatureActivated.

Extension de la fonctionnalité

Si vous examinez le fichier elements.xml, vous verrez qu'il existe un deuxième élément ListInstance. Il est utilisé pour créer une liste, appelée Clients, qui utilise le type de liste Contacts WSS intégré. Cet élément ListInstance démontre également comment ajouter des éléments par défaut à la liste afin de fournir des exemples de données client.

J'ai expliqué comment utiliser la logique déclarative CAML pour créer des listes et des bibliothèques de documents. Maintenant, je souhaite attirer votre attention sur le fait que vous pouvez créer une liste ou une bibliothèque de documents en utilisant du code personnalisé dans l'événement d'activation programmé selon le modèle d'objet WSS.

L'exemple de fonctionnalité inclut du code dans le gestionnaire d'événements FeatureActivated pour créer une autre liste à partir du type de liste personnalisé WSS standard appelé Letter Templates. Lorsque vous créez une liste à partir du type de liste personnalisé WSS standard, la liste contient automatiquement un champ appelé Titre. Mon code crée une deuxième colonne appelée Corps et utilise le modèle d'objet WSS pour ajouter des éléments de liste, qui fournissent les données utilisées comme modèles pour créer des lettres de client. Le code qui permet d'effectuer cette opération est reproduit à la figure 8.

  Figure 8 Créer une liste et ajouter une nouvelle colonne

Dim template As SPListTemplate = site.ListTemplates(“Custom List”)
Dim listLetterTemplatesID As Guid 
listLetterTemplatesID = site.Lists.Add(“Letter Templates”, “”, template)
Dim listLetterTemplates As SPList = site.Lists(listLetterTemplatesID)
listLetterTemplates.Fields.Add(“Body”, SPFieldType.Text, True)
listLetterTemplates.OnQuickLaunch = False
listLetterTemplates.Update()

Dim newLetterTemplate As SPListItem

newLetterTemplate = listLetterTemplates.Items.Add()
newLetterTemplate(“Title”) = “Initial Greeting”
newLetterTemplate(“Body”) = “Thanks for your recent interest in Litware.”
newLetterTemplate.Update()

newLetterTemplate = listLetterTemplates.Items.Add()
newLetterTemplate(“Title”) = “Follow Up”
newLetterTemplate(“Body”) = “Thanks for your recent purchase.”
newLetterTemplate.Update()

Pages d'application personnalisées

Il est important de comprendre le concept des fonctionnalités et leur utilisation, mais il existe un second composant fondamental dans la conception et le développement de solutions pour WSS et MOSS. L'architecture WSS prend en charge un type de page spécial appelé page d'application. La page Paramètres de site standard (settings.aspx) constitue un bon exemple de page d'application. La page settings.aspx est déployée une fois sur chaque serveur Web frontal, mais est accessible à partir de n'importe quel site d'une batterie de serveurs WSS.

Les pages d'application sont déployées en tant que fichiers physiques sur le système de fichiers du serveur Web frontal dans un répertoire accessible au chemin suivant :

%PROGRAMFILES%\common files\microsoft shared
   \web server extensions\12\TEMPLATE\LAYOUTS

WSS mappe le répertoire physique LAYOUTS sir le répertoire virtuel appelé _layouts lorsqu'il configure une application Web. À l'aide de cette structure de mappage, grâce à la logique de traitement supplémentaire, l'exécution WSS rend chaque page d'application accessible dans le contexte de n'importe quel site de la batterie de serveurs. Par exemple, imaginez qu'il y ait trois sites différents dans une batterie de serveurs WSS accessibles grâce à ces trois adresses URL :

http://Litwareinc.com
http://Litwareinc.com/sites/Vendors
http://Litwareinc.com:1001/sites/Accounting

Une page d'application est accessible en ajoutant son chemin relatif dans le répertoire _layouts à la fin de l'adresse URL d'un site. Par exemple, vous pouvez accéder à la page Paramètres du site à l'aide de l'une de ces adresses URL :

http://Litwareinc.com/_layouts/settings.aspx
http://Litwareinc.com/sites/Vendors/_layouts/settings.aspx
http://Litwareinc.com:1001/sites/Accounting/_layouts/settings.aspx

Dans la mesure où il n'y a qu'une version d'une page d'application à l'échelle de la batterie de serveurs, elle ne peut être compilée que dans une DLL et être chargée en mémoire qu'une seule fois. Vous ne devez jamais vous préoccuper de l'existence de plusieurs versions d'une page d'application pour différents sites. De plus, les pages d'application ne sont pas vulnérables aux attaques d'utilisateurs autorisés à personnaliser les pages du site. C'est pourquoi WSS ne les empêche pas de contenir du code en ligne.

Les pages d'application sont utilisées de façon intensive par l'équipe WSS pour la fourniture d'une bonne partie des fonctionnalités standard de configuration et d'administration des sites et des éléments. WSS prend également en charge les pages d'application personnalisée pour les solutions d'entreprise personnalisées. L'exemple de l'article du mois contient une page d'application personnalisée appelée Lettergenerator.aspx, qui est déployée comme toute autre page d'application dans le répertoire LAYOUTS.

Notez que Lettergenerator.aspx n'est pas déployé directement dans le répertoire LAYOUTS, mais dans un répertoire appelé OfficeSpace, qui se trouve dans le répertoire LAYOUTS. Il est recommandé de créer votre propre répertoire dans le répertoire LAYOUTS pour héberger les pages d'application personnalisées, pour éviter les éventuels conflits de dénomination.

Une page d'application est un type de page ASP.NET spécial, qui est généralement écrite de façon à hériter d'une classe de base appelée LayoutsPageBase et à se lier à la page de document maître standard, appelée application.master créée par l'équipe WSS. La figure 9 fournit un exemple de la page d'application personnalisée classique Hello World.

  Figure 9 Page d'application personnalisée Hello World

<%@ Assembly Name=”[Full assembly name for Microsoft.SharePoint]” %> 
<%@ Page Language=”VB” MasterPageFile=”~/_layouts/application.master” 
         Inherits=”Microsoft.SharePoint.WebControls.LayoutsPageBase” %>

<%@ Import Namespace=”Microsoft.SharePoint” %>

<script runat=”server”>
  Protected Overrides Sub OnLoad(e As EventArgs)
      MyBase.OnLoad(e)
      ‘*** get current site and web objects through WSS object model
      Dim siteCollection As SPSite = SPContext.Current.Site
      Dim site As SPWeb = SPContext.Current.Web
      ‘*** now program against WSS objects within the current site
      lblDisplay.Text = “Current site: “ & site.Title
  End Sub
</script>

<asp:Content ID=”Main” runat=”server”
             contentplaceholderid=”PlaceHolderMain” >
    <!-- ADD HTML elements and controls here for page content -->
    <asp:Label ID=”lblDisplay” runat=”server” />             
</asp:Content>

Comme vous pouvez le constater, il est possible de créer une page d'application qui contient des contrôles ASP.NET standard avec des remplacements de code dans une page ASP.NET standard, comme OnLoad. Vous pouvez également ajouter des références d'assembly. Si vous ajoutez une référence à Microsoft.SharePoint.dll, vous pouvez programmer sur la collection de sites actuelle et le site actuel en obtenant une référence par le biais de la classe SPContext, comme c'est le cas à la figure 9.

Une fois que vous avez ajouté une page d'application personnalisée à une solution, vous devez permettre aux utilisateurs d'y accéder. En ajoutant un élément CustomAction à une fonctionnalité, vous pouvez fournir un lien ou une option de menu. Voici un exemple d'élément CustomAction utilisé dans l'exemple OfficeSpaceFeature pour ajouter une option de menu à la liste déroulante Actions du site :

<CustomAction 
  Id=”OfficeSpaceLetterGenerator”
  GroupId=”SiteActions”
  Location=”Microsoft.SharePoint.StandardMenu”
  Sequence=”1001”
  Title=”OfficeSpace Letter Generator”    
  Description=”Create letter using Open XML”
  ImageUrl=”/_layouts/images/crtpage.gif” >

    <UrlAction Url=”~site/_layouts/OfficeSpace/LetterGenerator.aspx”/>

</CustomAction>

Cet élément CustomAction ajoute l'option de menu personnalisée au menu standard Actions du site. L'élément UrlAction dans l'élément CustomAction fournit un attribut Url avec un chemin relatif vers ma page d'application personnalisée. La valeur de chaîne affectée à l'attribut Url possède un jeton dynamique sous forme de ~site. Elle est remplacée par WSS lors de l'exécution avec le chemin réel d'accès au site actuel.

Lorsque des utilisateurs sélectionnent l'option de menu personnalisée, ils sont redirigés vers la page d'application personnalisée appelée LetterGenerator.aspx, qui affiche l'interface utilisateur présenté illustrée à la figure 10. Un code de la méthode OnLoad de cette page permet de remplir deux zones de liste avec le client et le type de lettre de votre choix. Il utilise le modèle d'objet WSS pour extraire les données des deux listes créées lors de l'activation de la fonctionnalité. Il existe également deux boutons de commande qui permettent deux approches différentes de la création de lettres de clients sous forme de fichiers .docx, à l'aide du code présentée dans mon article précédent d'Office Space.

Figure 10 Page d'application personnalisée (Cliquer sur l'image pour l'agrandir)

Lorsque l'utilisateur clique sur l'un des boutons de commande, le gestionnaire d'événements exécute le code pour générer une lettre à l'aide des formats de fichier ouvert Office. Ce code est presque identique à celui présenté dans mon article précédent. Il diffère uniquement au niveau du code utilisé pour nommer le fichier et l'enregistrer dans la bibliothèque de documents WSS appelée Customer Letters.

Cet exemple décrit l'automatisation de la création de lettres de clients à l'aide des formats de fichier XML ouvert Office, et la synergie qui est observée entre WSS et ces formats de fichier.

Lorsque vous créez un fichier new.docx, vous devez disposer d'un emplacement dans lequel l'enregistrer. WSS propose un emplacement idéal pour stocker des documents, dans lequel ils peuvent être versionnés et mis à disposition d'une équipe qui travaille dans un environnement de collaboration. La figure 11illustre la bibliothèque de documents Customer Letters sur un site qui a activé ma fonctionnalité OfficeSpaceFeature.

Figure 11 Bibliothèque de documents Customer Letters (Cliquer sur l'image pour l'agrandir)

Résumé

L'article de ce mois présente les fonctionnalités et les pages d'application personnalisées : deux composants essentiels utilisés pour concevoir et mettre en œuvre des solutions pour WSS et MOSS. À ce stade, vous devez avoir savoir comment commencer à développer et à tester. Dans le prochain numéro d'Office Espace, j'aborderai l'empaquetage de solutions comme celle que je viens de décrire pour le déploiement dans un environnement de production.

Envoyez vos questions et commentaires à l'attention de Ted à l'adresse suivante :  instinct@microsoft.com.

Ted Pattison est auteur, formateur et MVP Sharepoint. Il vit à Tampa en Floride. Il vient juste de terminer son manuel Inside Windows SharePoint Services 3.0 pour Microsoft Press. Il dispense également une formation Sharepoint avancée à des développeurs professionnels par le biais de son entreprise, Ted Pattison Group.

Source :http://msdn.microsoft.com/fr-fr/magazine/cc163428.aspx