Partager via

Importation des éléments d’un site SharePoint existant

  • Article

Le modèle de projet Importer le package de solution SharePoint permet de réutiliser des éléments de sites SharePoint existants (par exemple des types de contenu et des champs) dans une nouvelle solution SharePoint Visual Studio. Vous pouvez exécuter la plupart des solutions importées sans aucune modification, mais il existe certaines restrictions et complications à prendre en compte, en particulier si vous modifiez des éléments après les avoir importés.

Notes

Pour importer des flux de travail réutilisables, utilisez le modèle de projet Importer le flux de travail réutilisable. Pour plus d’informations, consultez Instructions relatives à l’importation de flux de travail réutilisables.

Solutions SharePoint prises en charge

Visual Studio 2012 prend entièrement en charge l’importation de solutions créées dans SharePoint Foundation et SharePoint Server.

Visual Studio 2012 ne prend pas en charge l’importation de solutions créées dans les applications suivantes :

  • Windows SharePoint Services 3.0

  • Microsoft Office SharePoint Server 2007

  • Visual Studio 2008

  • Microsoft SharePoint Designer 2007

  • Visual Studio 2010

    Bien que vous puissiez généralement importer des solutions créées par ces applications, cette fonctionnalité n’est ni testée, ni prise en charge.

Restrictions relatives à l’importation d’éléments

Bien que la plupart des éléments SharePoint puissent être importés à partir d’un fichier .wsp existant, les éléments suivants ne sont pas pris en charge, car des modifications risquent de se révéler nécessaires à leur bon fonctionnement :

  • Entités BDC

  • Éléments d’association de flux de travail de code

  • Flux de travail de code

  • Composants Visual Web Parts (.ascx)

  • Services web (.asmx)

  • Liaisons de type de contenu

  • Récepteurs d’événements

  • Définitions de listes (modèles)

  • Définitions de sites

    Lorsque vous exportez une solution à partir de SharePoint Foundation ou de SharePoint Server, ces éléments sont exclus automatiquement du fichier .wsp. Ils peuvent toutefois figurer dans d’autres fichiers .wsp générés à partir d’outils non pris en charge. (Voir « Solutions SharePoint prises en charge » plus haut dans cette rubrique.)

Conséquences de l’importation d’une solution

Lorsque vous importez une solution avec le modèle Importer le package de solution SharePoint, Visual Studio copie tout le contenu du fichier .wsp, et tente de rapprocher et de conserver le plus d’associations et de références possibles entre les éléments importés et leurs fichiers.

Tous les éléments importés sont copiés dans des dossiers correspondants dans l’ Explorateur de solutions. Par exemple, les types de contenu apparaissent sous le dossier Types de contenu et les instances de listes apparaissent sous Instances de listes. Les fichiers associés à un élément importé sont également copiés dans le dossier de l’élément. Par exemple, une instance de liste importée comprend ses modules, formulaires et pages ASPX.

Éléments dépendants

Si vous sélectionnez un élément dans l’Assistant Importer le package de solution SharePoint, mais pas ses éléments dépendants, une boîte de message vous signale que les éléments dépendants doivent aussi être sélectionnés avant l’importation.

Fonctionnalités

Les utilisateurs de SharePoint Designer peuvent voir des fichiers inattendus, appelés fonctionnalités, apparaître dans leurs solutions importées dans l’Explorateur de solutions. Les fonctionnalités existaient dans la solution SharePoint Designer, mais elles étaient masquées. Elles sont désormais visibles dans Visual Studio.

Les fonctionnalités sont des conteneurs d’éléments SharePoint. Chaque fonctionnalité conserve une référence à chaque élément qu’elle contient, comme les types de contenu et les définitions de listes. Lorsque vous importez votre solution, Visual Studio configure des fonctionnalités pour tous les éléments importés et tente de conserver les relations entre les fonctionnalités et les éléments pour les fichiers. Tous les fichiers dont les références n’ont pas pu être résolues sont placés dans le dossier Autres fichiers importés .

Pour plus d’informations sur les fonctionnalités, consultez Développement de solutions SharePoint et Utilisation des fonctionnalités.

Gestion des cas spéciaux

Dans certains cas, Visual Studio ne peut pas rapprocher un élément de ses fichiers dépendants. Tous les fichiers que Visual Studio n’a pas pu résoudre apparaissent sous le dossier Autres fichiers importés. En outre, leurs propriétés DeploymentType prennent la valeur NoDeployment pour qu’ils ne soient pas déployés avec la solution.

Par exemple, si vous importez la définition de liste ExpenseForms, une définition de liste du même nom apparaît sous le dossier Définitions de listes dans l’Explorateur de solutions, avec ses fichiers Elements.xml et Schema.xml. Toutefois, ses formulaires ASPX et HTML associés peuvent être placés dans un dossier nommé ExpenseForms sous le dossier Autres fichiers importés . Pour terminer l’importation, déplacez ces fichiers sous la définition de liste ExpenseForms dans l’ Explorateur de solutions et modifiez la propriété DeploymentType de chaque fichier de NoDeployment en ElementFile.

Quand vous importez des récepteurs d’événements, le fichier Elements.xml est copié au bon emplacement. Cependant, vous devez inclure manuellement l’assembly dans le package de solution pour qu’il soit déployé avec la solution. Pour savoir comment faire, consultez Guide pratique : Ajout et suppression d’assemblys supplémentaires.

Quand vous importez des flux de travail, les formulaires InfoPath sont copiés dans le dossier Autres fichiers importés . Si le fichier .wsp contient un modèle web, il est défini comme page d’accueil dans l’Explorateur de solutions.

Importation de champs et de conteneurs des propriétés

Quand vous importez une solution comportant plusieurs champs, toutes les définitions de champs distinctes sont fusionnées dans un même fichier Elements.xml, sous un nœud de l’Explorateur de solutions nommé Champs. De même, toutes les entrées du conteneur des propriétés sont fusionnées dans un fichier Elements.xml, sous un nœud nommé PropertyBags.

Dans SharePoint, les champs sont des colonnes d’un type de données spécifié, tel que texte, valeur booléenne ou recherche. Pour plus d’informations, consultez Bloc de construction : Colonnes et types de champs. Les conteneurs des propriétés vous permettent d’ajouter des propriétés à toutes sortes d’objets dans SharePoint, d’une batterie de serveurs entière à une simple liste sur un site SharePoint. Ils sont implémentés en tant que table de hachage de noms et de valeurs de propriétés. Pour plus d’informations, consultez Gestion de la configuration de SharePoint ou Paramètres des conteneurs des propriétés SharePoint.

Suppression d’éléments dans le projet

La plupart des éléments dans les solutions SharePoint ont un ou plusieurs éléments dépendants. Par exemple, les instances de listes dépendent des types de contenu et les types de contenu dépendent des champs. Si, une fois que vous avez importé une solution SharePoint, vous supprimez un élément dans la solution mais non les éléments dépendants, Visual Studio ne vous signale les éventuels problèmes de référence que lorsque vous tentez de déployer la solution. Par exemple, si une solution importée comporte une instance de liste qui dépend d’un type de contenu et que vous supprimez ce type de contenu, une erreur peut se produire pendant le déploiement. L’erreur se produit si l’élément dépendant n’est pas présent sur le serveur SharePoint. De même, si un élément supprimé est également associé à un conteneur des propriétés, vous devez supprimer ces entrées du fichier PropertyBags Elements.xml. Ainsi, si vous supprimez des éléments d’une solution importée et que des erreurs de déploiement se produisent, vérifiez si des éléments dépendants doivent également être supprimés.

Restauration d’attributs de fonctionnalités manquants

Lors de l’importation de solutions, certains attributs de fonctionnalités facultatifs sont omis du manifeste de fonctionnalité importé. Si vous souhaitez restaurer ces attributs dans le nouveau fichier de fonctionnalités, identifiez les attributs manquants en comparant le fichier de fonctionnalités d’origine au nouveau manifeste de fonctionnalités et suivez les instructions données dans la rubrique Guide pratique : Personnalisation d’une fonctionnalité SharePoint.

Détection de conflit de déploiement non effectuée sur les instances de listes intégrées

Visual Studio n’effectue pas de détection de conflit de déploiement sur les instances de listes intégrées (c’est-à-dire les instances de listes par défaut fournies avec SharePoint). La non-détection des conflits a pour but d’éviter le remplacement des instances de listes intégrées dans SharePoint. Les instances de listes intégrées sont toujours déployées ou mises à jour, mais ne sont jamais supprimées ou remplacées. Pour plus d’informations, consultez Résolution des problèmes de création de packages et de déploiement SharePoint.

Importation de flux de travail SharePoint Server 2010

Un flux de travail créé dans SharePoint Server ne s’exécute pas correctement une fois importé et déployé. En effet, certains assemblys sont manquants. Par ailleurs, les flux de travail SharePoint Server contiennent des formulaires InfoPath qui ne sont actuellement pas pris en charge dans les solutions de flux de travail Visual Studio. Les flux de travail SharePoint Server importés peuvent toutefois fonctionner correctement après quelques corrections, notamment l’ajout de références aux assemblys SharePoint Server et la reconnexion des formulaires InfoPath. Pour plus d’informations, consultez Importation de flux de travail SharePoint Server 2010.

Nombre limite de caractères du nom des éléments

Visual Studio impose une limite de 260 caractères sur le nom des projets et des éléments de projet, chemin compris. Pendant l’importation d’une solution, si un nom d’élément dépasse cette limite, l’erreur suivante s’affiche :

Le chemin d’accès et/ou le nom de fichier spécifiés sont trop longs. Le nom du fichier complet doit être inférieur à 260 caractères et le nom du répertoire à 248 caractères.

Quand cette erreur se produit, l’élément n’est pas créé. Ce problème se produit le plus souvent avec les modules importés. Pour l’éviter, procédez comme suit :

  • Utilisez des noms courts pour vos projets quand vous les entrez dans la boîte de dialogue Ajouter un nouveau projet .

  • Créez le projet dans un emplacement le plus près possible du dossier racine, afin de raccourcir le chemin d’accès.

Attribut SharePointProductVersion

Si vous importez une solution créée dans une version antérieure de SharePoint (par exemple Windows SharePoint Services 3.0 ou Microsoft Office SharePoint Server 2007), vous devez soit remplacer par 12.0 la valeur de l’attribut SharePointProductVersion dans le manifeste du package, soit insérer un contrôle de gestionnaire de scripts dans toutes les pages web importées en conservant la valeur 14.0 pour l’attribut SharePointProductVersion. Autrement, les formulaires web importés ne s’afficheront pas dans SharePoint.

Arrière-plan

Les solutions créées dans SharePoint Foundation et SharePoint Server incluent un attribut appelé SharePointProductVersion. SharePoint utilise cet attribut dans ses manifestes de packages pour déterminer la version de SharePoint pour laquelle la solution est conçue. Les deux valeurs valides sont 12.0 et 14.0. La valeur 12.0 indique que l’élément est conçu pour Windows SharePoint Services 3.0 ou Microsoft Office SharePoint Server 2007, la valeur 14.0 pour SharePoint Foundation ou SharePoint Server.

Pour renforcer la sécurité du rendu des pages ASPX, SharePoint Foundation et SharePoint Server exigent que toutes les pages ASPX et pages maîtres contiennent un contrôle de gestionnaire de scripts. Pour plus d’informations sur le gestionnaire de scripts, consultez Vue d’ensemble du contrôle ScriptManager. Or, le contrôle de gestionnaire de scripts n’était pas disponible dans Windows SharePoint Services 3.0 et Microsoft Office SharePoint Server 2007. Il doit donc être ajouté à toute page Windows SharePoint Services 3.0 ou Microsoft Office SharePoint Server 2007 mise à niveau vers SharePoint Foundation ou SharePoint Server. Les pages ASPX qui utilisent une page maître standard ne nécessitent pas de contrôle de gestionnaire de scripts, car un contrôle de ce type a déjà été ajouté à la page maître standard. En revanche, les pages ASPX qui n’utilisent pas de page maître ou qui emploient une page maître personnalisée doivent intégrer un contrôle de script pour pouvoir fonctionner dans SharePoint Foundation ou SharePoint Server.

L’absence de contrôle de gestionnaire de scripts peut poser problème pour importer un projet Windows SharePoint Services 3.0 ou Microsoft Office SharePoint Server 2007 dans Visual Studio 2010, car l’attribut SharePointProductVersion de tous les nouveaux projets a la valeur 14.0. Si vous déployez un projet mis à niveau comportant un formulaire web sans gestionnaire de scripts, le formulaire ne s’affichera pas dans SharePoint.

Voir aussi