Redéploiement de personnalisations et de solutions dans SharePoint Foundation 2010 et SharePoint Server 2010

Article
07/02/2015

Résumé : découvrez comment redéployer des personnalisations et des solutions personnalisées créées pour Windows SharePoint Services 3.0 et Microsoft Office SharePoint Server 2007 dans Microsoft SharePoint Server 2010 et Microsoft SharePoint Foundation 2010.

Dernière modification : mercredi 12 janvier 2011

James Crowley, Microsoft Corporation

Dans cet article
Mise en route avec le modèle objet 2010
Installation des mises à niveau
Utilisation du modèle objet 2010
Modifications apportées à l’interface utilisateur
Conclusion
Ressources supplémentaires

Michael Washam, Microsoft Corporation

Octobre 2009

Sommaire

Mise en route avec le modèle objet 2010
Installation des mises à niveau
Utilisation du modèle objet 2010
Modifications apportées à l’interface utilisateur
Conclusion
Ressources supplémentaires

Téléchargez la liste des types et méthodes obsolètes qui accompagne cet article :Microsoft SharePoint Server 2010: types et méthodes obsolètes (éventuellement en anglais)

Mise en route avec le modèle objet 2010

Microsoft SharePoint Foundation 2010 et Microsoft SharePoint Server 2010 contiennent des mises à niveau du modèle objet qui ont été conçues pour être compatibles avec les solutions existantes développées pour Windows SharePoint Services 3.0 et Microsoft Office SharePoint Server 2007. Bien que certains espaces de noms et certaines classes et méthodes soient désormais obsolètes, ces éléments sont toujours disponibles et continuent à fonctionner comme prévu dans le code personnalisé. En outre, malgré un changement significatif de l’interface utilisateur (IU), le mode visuel de compatibilité descendante permet de conserver les personnalisations visuelles jusqu’à ce que vous puissiez intégrer les améliorations de l’interface utilisateur. Vous pouvez synchroniser vos personnalisations et applications avec les versions mises à niveau de Microsoft SharePoint Foundation 2010 et Microsoft SharePoint Server 2010 une fois que vous les avez redéployées. Cet article donne des conseils et des instructions pour surmonter les obstacles que vous risquez de rencontrer lors du redéploiement, du test et du débogage de votre code Windows SharePoint Services 3.0 et Office SharePoint Server 2007 dans SharePoint Foundation 2010 et Microsoft SharePoint Server 2010, respectivement.

Si vous avez créé des projets Windows SharePoint Services 3.0 ou Office SharePoint Server 2007 avec les extensions Microsoft Visual Studio 2005 pour Windows SharePoint Services 3.0, version 1.1, les extensions Microsoft Visual Studio 2005 pour Windows SharePoint Services 3.0, version 1.2 et les extensions Microsoft Visual Studio 2005 pour Windows SharePoint Services 3.0, version 1.3, vous pouvez les mettre à niveau à l’aide de l’outil de mise à niveau VSeWSS (éventuellement en anglais) qui installe des modèles convertissant des packages de solutions existants des extensions Visual Studio pour SharePoint Services (écrits en Microsoft Visual Basic ou en Microsoft Visual C#) en solutions Microsoft Visual Studio 2010 (figure 1).

Figure 1. Importation d’un projet des extensions Visual Studio pour Windows SharePoint Services dans Visual Studio 2010

Importer VSeWSS dans Visual Studio 2010

Une fois les projets des extensions Visual Studio pour Windows SharePoint Services convertis en solutions Visual Studio 2010, vous devez déployer vos nouveaux packages de solution sur la structure mise à niveau.

Installation des mises à niveau

Vous pouvez effectuer vos mises à niveau sur place (sur une batterie de serveurs sur laquelle Windows SharePoint Services 3.0 ou Office SharePoint Server 2007 sont déjà installés) ou sur une nouvelle batterie à laquelle l’administrateur ou vous-même attacherez votre base de données de contenu existante. Dans les deux cas, les performances des redéploiements seront optimales si vous avez recours à des fichiers de package de solution (.wsp) SharePoint plutôt qu’à des packages Windows Installer (.msi). Si vous avez besoin de redéployer un modèle de site, vous devez créer un site à partir du modèle et l’enregistrer en tant que package de solution. Le point le plus important est de veiller à ce que le dossier « 14 » soit l’emplacement cible de tous les déploiement, et non le dossier « 12 » (les packages de solution simplifient cette vérification). SharePoint Foundation 2010 et SharePoint Server 2010 vérifient le contenu du dossier 12\TEMPLATE\FEATURES si ces programmes ne trouvent pas un fichier dans le dossier « 14 » correspondant. Ces programmes risquent toutefois de ne pas trouver les fichiers personnalisés déployés dans d’autres dossiers. De plus, il est bien plus facile de déboguer vos installations si tous les fichiers personnalisés sont déployés dans le dossier « 14 ».

Utilisation de packages de solution (fichiers .wsp)

Si possible, déployez vos solutions personnalisées à l’aide de packages de solution (fichiers .wsp). C’est le meilleur moyen de s’assurer que tous les fichiers personnalisés sont déployés sur les emplacements corrects. Pour plus d’informations sur la création de fichiers de solution dans Windows SharePoint Services 3.0 et Office SharePoint Server 2007, voir Création d’une solution. Pour plus d’informations sur le déploiement de fichiers de solution dans SharePoint Foundation 2010 et SharePoint Server 2010, voir Installation et déploiement d'une solution de batterie de serveurs.

Utilisation de fichiers Windows Installer

Si vous déployez vos solutions personnalisées à l’aide de packages Windows Installer (.msi), veillez à les modifier pour que les fichiers personnalisés soient déployés aux emplacements corrects dans le dossier « 14 ». Cela s’applique tout particulièrement si vous déployez les fichiers à des endroits autres que le dossier TEMPLATE\FEATURES.

Redéploiement de modèle de site

Les modèles de site sont obsolètes. Si vous devez redéployer un modèle de site sur SharePoint Foundation 2010 ou SharePoint Server 2010, procédez comme suit :

Créez un site à partir du modèle de site.
Installez SharePoint Foundation 2010 ou SharePoint Server 2010 sur une batterie de serveurs existante ou nouvelle. Si vous installez les mises à niveau sur une nouvelle batterie, attachez la base de données de contenu qui comporte le site créé à la nouvelle batterie.
Sur la nouvelle installation, choisissez Enregistrer le site en tant que modèle dans la page Paramètres du site pour créer un package de solution doté de l’extension de nom de fichier .wsp.

Utilisation du modèle objet 2010

Bien que de nombreuses améliorations et modifications aient été apportées au modèle objet, vous pouvez toujours compiler votre code personnalisé, et celui-ci s’exécute comme prévu, à une exception éventuelle près. Si vos personnalisations reposent sur des requêtes de liste pouvant générer des jeux de résultats avec plus de 5 000 éléments ou pouvant analyser toutes les lignes de listes composées de plus de 5 000 éléments, vous devez modifier le seuil de taille des requêtes (pour obtenir des instructions, reportez-vous à Limitation des requêtes de liste volumineuse). Sinon, vous pouvez vous pencher sur les modifications et incorporer les nouveaux éléments du modèle objet selon votre propre calendrier. Le modèle objet mis à niveau offre d’autres solutions qui permettent d’améliorer, dans de nombreux cas, la conception et les performances de vos personnalisations.

Compatibilité descendante

Comme les modifications apportées à l’API dans le cadre des mises à niveau sont à compatibilité descendante, vous ne devriez pas avoir à effectuer de changement dans votre code personnalisé avant de le redéployer dans SharePoint Foundation 2010 ou SharePoint Server 2010. Bien que certaines classes et certains espaces de noms soient obsolètes, ils fonctionnent toujours comme prévu. Si vous souhaitez mettre à niveau vos applications pour qu’elles utilisent les classes et méthodes les plus récentes, recompilez votre code. Les avertissements du compilateur vous indiquent les éléments obsolètes du modèle objet et les nouveaux éléments que vous devez utiliser. La figure 2 montre un exemple d’avertissement du compilateur et l’avertissement correspondant au passage de la souris dans Visual Studio 2010.

Figure 2. Avertissement du compilateur relatif à un constructeur obsolète dans Visual Studio 2010

Avertissement du compilateur dans Visual Studio 2010

Pour obtenir la liste des types et méthodes obsolètes dans le modèle objet Microsoft SharePoint 2010, voir Microsoft SharePoint Server 2010 : types et méthodes obsolètes (éventuellement en anglais).

SharePoint Server 2010 contient plus de 1 500 types obsolètes dont la plupart figure dans l’espace de noms Microsoft.SharePoint.Portal. SharePoint Foundation 2010 comporte un nombre bien inférieur de types obsolètes ; il contient toutefois plusieurs centaines de méthodes et de propriétés obsolètes.

Il n’est pas nécessaire de recompiler le code personnalisé qui a été écrit pour Windows SharePoint Services 3.0 et Office SharePoint Server 2007 lorsqu’il s’exécute sur les Services Internet (IIS). Cela signifie que vous pouvez réutiliser les fichiers .dll personnalisés sans les recompiler. Dans certains cas, ces fichiers risquent toutefois de ne pas fonctionner comme prévu. Si vous avez par exemple redéployé tous les fichiers dans le dossier « 14 » et avez vidé le dossier « 12 », les références aux fichiers du dossier « 12 » ne fonctionnent pas. Tout comme vous devez réécrire les packages Windows Installer s’ils font référence à des emplacements dans le dossier « 12 », vous devez réécrire et recompiler le code faisant référence aux fichiers et ressources que vous avez déplacés vers de nouveaux emplacements. Vous devez évaluer vos personnalisations en ce qui concerne la nouvelle installation et veiller à ce que le code reposant sur des éléments spécifiques de votre anciennes installation fonctionnera une fois les mises à niveau installées.

Vous devez recompiler le code personnalisé écrit pour Office SharePoint Server 2007 si la solution contient un récepteur de fonctionnalité qui implémente les méthodes FeatureInstalled, FeatureUninstalling, FeatureActivated ou FeatureDeactivating et si vous procédez au déploiement à l’aide de l’outil en ligne de commande Stsadm ou du service du minuteur. Les redirections d’assembly dans SharePoint Server 2010 sont gérées par des entrées du fichier web.config sur le serveur, et les outils en ligne de commande risquent de ne pas effectuer les redirections vers les nouvelles versions d’assembly tant que votre solution n’est pas installé.

Vous devez recompiler le code personnalisé destiné à Windows SharePoint Services 3.0 et Office SharePoint Server 2007 qui ne s’exécute pas sur IIS (comme les services et les applications console).

Limitation des requêtes de liste volumineuse

SharePoint Foundation 2010 et SharePoint Server 2010 appliquent un seuil de requête par défaut de 5 000 éléments. Tout code personnalisé qui repose sur des jeux de résultats de requête pouvant dépasser ce seuil maximal ne se comporte pas comme prévu après la mise à niveau. Les requêtes sur des listes composées de plus de 5 000 éléments comportant des champs non indexés dans leurs conditions de requête échouent également, car elles doivent analyser toutes les lignes d’une liste. Vous pouvez augmenter cette limite (en définissant la propriété EnableThrottling sur l’objet SPList) ou autoriser le modèle objet à la remplacer. Pour obtenir des conseils et des instructions pour gérer efficacement des dossiers et des listes volumineux, consultez les articles Gestion de dossiers et de listes volumineux et Écriture d’un code efficace dans SharePoint Server.

Augmenter le seuil des requêtes par défaut

Sur le site Administration centrale, sous Gestion des applications, cliquez sur Gérer les applications Web.
Cliquez sur Paramètres généraux, puis sur Limitation de ressource (figure 3).

Figure 3. Définition du seuil de taille des requêtes dans SharePoint Foundation 2010 et SharePoint Server 2010

Définition du seuil pour la taille des requêtes

Nouvelles fonctionnalités SharePoint

Les ajouts importants au modèle objet SharePoint Foundation 2010 et SharePoint Server 2010 comportent de nouvelles fonctionnalités, notamment :

L’espace de noms Microsoft.SharePoint.Linq qui définit un fournisseur LINQ vers SharePoint convertissant des requêtes LINQ en requêtes CAML (Collaborative Application Markup Language) (vous donnant ainsi la possibilité de remplacer vos requêtes CAML et de liste par LINQ).
Trois API côté client dans l’espace de noms Microsoft.SharePoint.Client qui permettent d’interagir avec des sites SharePoint par le biais de scripts s’exécutant dans le navigateur à partir de code managé Microsoft .NET Framework et dans des applications Microsoft Silverlight.
SharePoint Foundation 2010 et SharePoint Server 2010 comportent de nombreux ajouts provenant de Business Connectivity Services. Ces modifications facilitent l’intégration de processus et données métiers externes à des applications serveur et clientes.

Pour obtenir des informations sur l’utilisation de ces éléments et des autres nouvelles API, consultez les articles Nouveautés de SharePoint Foundation 2010 et Nouveautés dans SharePoint Server 2010.

Le graphique de la figure 4 montre les espaces de noms auxquels ont été ajoutés de nombreux types.

Figure 4. Nouveaux types par espace de noms dans SharePoint Server 2010

Nouveaux types par espaces de noms

Modifications apportées à l’interface utilisateur

L’interface utilisateur de SharePoint Foundation 2010 et SharePoint Server 2010 ayant changé de façon significative, les personnalisations reposant sur des classes CSS et des éléments d’interface utilisateur spécifiques sont optimisées en mode de compatibilité descendante. Lorsque vous effectuez une mise à niveau vers SharePoint Foundation 2010 ou SharePoint Server 2010, vous avez la possibilité de choisir le mode de compatibilité descendante ou l’interface utilisateur mise à niveau. Vous pouvez passer du mode de compatibilité descendante à la nouvelle interface au niveau de la collection de sites ou du site :

Pour conserver l’aspect des sites existants, utilisez PSConfig ou PSConfigUI.
Pour conserver l’aspect des sites existants lorsque vous effectuez une mise à niveau en attachant votre ancienne base de données de contenu à une nouvelle batterie de serveurs, utilisez Stsadm.

Vous avez également la possibilité d’avoir recours à l’interface Web pour définir tous les sites d’une collection sur l’interface utilisateur mise à niveau (et empêcher ainsi les utilisateurs d’utiliser l’ancienne interface).

Définir tous les sites d’une collection sur l’interface utilisateur mise à niveau

Sous Paramètres du site, cliquez sur Administration de la collection de sites.
Cliquez sur Supported User Experiences (figure 5).

Figure 5. Changement de l’interface utilisateur au niveau de la collection de sites

Changement de l’interface utilisateur au niveau de la collection de sites

Vous pouvez également modifier l’aspect précédent d’un site spécifique. Pour ce faire, sous Paramètres du site, cliquez sur Titre, sur Description, puis sur Apparence (figure 6).

Figure 6. Changement de l’interface utilisateur au niveau du site

Changement de l’interface utilisateur au niveau du site

Vous avez aussi la possibilité d’obtenir ou de définir par programme la version de l’interface utilisateur (3 pour le mode de compatibilité descendante et 4 pour la nouvelle interface) à l’aide de la propriété SPWeb.UIVersion.

Notes

Après avoir attribué la valeur 3 ou 4 à la propriété SPWeb.UIVersion, vous devez utiliser la méthode SPWeb.Update pour enregistrer la modification.

La propriété UIVersion est également disponible pour les contrôles SharePoint:VersionedContent et SharePoint:VersionedPlaceHolder. Ces deux contrôles placent le contenu des versions sur la page, mais le contrôle SharePoint:VersionedPlaceHolder fonctionne au moment du rendu, une fois que la page a été entièrement chargée.

Les exemples ci-après illustrent l’implémentation de ces contrôles dans les fichiers .aspx.

<SharePoint:VersionedPlaceHolder ID="vph4" runat="server" UIVersion="4">
   <div>Content</div>
</SharePoint:VersionedPlaceHolder>

<SharePoint:UIVersionedContent ID="vc4" runat="server" UIVersion="4">
<ContentTemplate>
<div>Content</div>
</ContentTemplate>
<SharePoint:UIVersionedContent>

Vous pouvez activer ou désactiver par programme le paramètre Supported User Experiences dans l’interface Web en définissant les propriétés booléennes SPWeb.UIVersionConfigurationEnabled, SPSite.UIVersionConfigurationEnabledInAllWebs et SPSite.UIVersionConfigurationEnabled. Attribuer la valeur false à SPSite.UIVersionConfigurationEnabled revient à sélectionner l’option Commit new user experience sous Actions du site. Dans les deux cas, vous ne pouvez plus passer d’une version à l’autre de l’interface utilisateur à l’aide de l’interface Web (bien que vous puissiez toujours passer de l’une à l’autre par programme en définissant les propriétés précédemment mentionnées).

En mode de compatibilité descendante, vos personnalisations visuelles fonctionnent toujours et vous avez accès à l’intégralité de l’infrastructure (notamment la feuille de style CSS) liée aux thèmes. Ce mode vous permet d’effectuer la mise à niveau et la migration de vos personnalisations à votre rythme de sorte qu’elles fonctionnent avec la nouvelle interface. Certains éléments visuels fonctionnent comme prévu dans la nouvelle interface. En revanche, quelques actions personnalisées (celles utilisant les attributs ControlAssembly, ControlClass et ControlSrc) ne fonctionnent pas. Si vous avez effectué de nombreuses personnalisations visuelles, notamment des personnalisations de feuille de style CSS et de barre d’outils, vous devez d’abord utiliser le mode de compatibilité descendante. Une fois les personnalisations redéployées, vous devez les tester avec l’interface mise à niveau pour déterminer quels éléments doivent être changés.

Modifications apportées aux classes CSS

La nouvelle feuille de style CSS ayant changé de façon significative, les personnalisations et conceptions reposant sur les classes CSS de Windows SharePoint Services 3.0 et Office SharePoint Server 2007 ne fonctionnent qu’en mode de compatibilité descendante. Comme les thèmes n’existent plus dans SharePoint Foundation 2010 et SharePoint Server 2010, les personnalisations et le travail de conception que vous avez effectués avec des thèmes ne sont pas importés dans la nouvelle interface. Lorsque vous reconcevez des pages après une mise à niveau et un redéploiement, vous devez personnaliser la nouvelle page maître plutôt que d’essayer de faire fonctionner votre ancienne feuille de style CSS avec la nouvelle interface utilisateur.

Actions personnalisées et ajouts aux barre d’outils

La plupart des actions personnalisées, notamment celles ciblant les liens et les menus de bloc de contrôle d’édition, fonctionne toujours comme prévu dan l’interface mise à niveau. Les barres d’outils étant remplacées par le Ruban, la plupart des actions personnalisées ajoutant des boutons à une barre d’outils sont placées sous l’onglet Commandes personnalisées du Ruban (figure 7).

Figure 7. Actions personnalisées sur la barre d’outils et sous l’onglet Commandes personnalisées du Ruban

Actions personnalisées sur la barre d’outils et dans le Ruban

Tout Custom Action Element utilisant les attributs ControlAssembly, ControlClass ou ControlSrc, n’apparaît toutefois pas dans la nouvelle interface. Pour que ces ajouts aux barres d’outils fonctionnent avant toute reconception de l’application, vous pouvez utiliser le mode de compatibilité descendante. Vous avez également la possibilité de sélectionner l’option Afficher la barre d’outils complète pour chaque affichage de liste et formulaire de liste qui utilise une barre d’outils contenant ce type d’action personnalisée. L’option Afficher la barre d’outils complète entraîne l’affichage de la barre d’outils avec le Ruban. Bien que cela puisse créer des fonctionnalités en double, cette option peut être adaptée si vos barres d’outils personnalisées apparaissent dans peu de cas.

Conclusion

Vous pouvez tirer parti des fonctionnalités améliorées de SharePoint Foundation 2010 et SharePoint Server 2010 dès leur installation et il n’est pas nécessaire de réécrire immédiatement votre code. Tous les éléments obsolètes de l’API sont toujours disponibles de sorte que vous ayez le temps de passer en revue les nouveaux éléments de l’API avant de les incorporer dans vos personnalisations. De plus, le mode de compatibilité descendante vous offre la possibilité de revoir vos personnalisations et, si nécessaire, de les reconcevoir pour qu’elles exploitent la nouvelle interface utilisateur. Vous n’êtes également pas obligé d’adopter simultanément la nouvelle interface utilisateur pour tous les sites. L’ancienne version de l’interface peut toujours être appliquée à certains sites, tandis que d’autres adoptent la nouvelle version. La structure vous offre la possibilité de migrer vos personnalisations et de tirer parti des nouvelles fonctionnalités de façon méthodique et par étape, afin que vous puissiez adopter les améliorations à votre rythme.

Partager via