Importation d'éléments d'un site SharePoint existant
Le modèle de projet Importer le package de solution SharePoint permet de réutiliser, dans une nouvelle solution SharePoint Visual Studio, des éléments (tels que des types de contenu et des champs) provenant de sites SharePoint existants. Bien que vous puissiez exécuter la plupart des solutions importées sans aucune modification, vous devez tenir compte de quelques points et restrictions, surtout 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 Directives pour l'importation de flux de travail réutilisables.
Solutions SharePoint prises en charge
Visual Studio 2010 prend en charge intégralement l'importation de solutions créées dans SharePoint Foundation 2010 et SharePoint Server 2010.
Visual Studio 2010 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
Notes
En d'autres termes, Visual Studio 2010 ne prend pas en charge l'importation de solutions SharePoint créées dans Visual Studio 2010.
Bien que vous puissiez généralement importer des solutions créées par ces applications, cette fonctionnalité n'est pas 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 et peuvent nécessiter des modifications pour fonctionner correctement :
Entités BDC
Éléments d'association des flux de travail avec code
Flux de travail avec code
Composants Visual Web Part (.ascx)
Service 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 2010 ou de SharePoint Server 2010, ces éléments sont automatiquement exclus du fichier .wsp. Toutefois, d'autres fichiers .wsp générés à partir d'outils non pris en charge peuvent contenir ces éléments. (Consultez la section « SharePoint Solutions Pris en charge » présentée précédemment dans cette rubrique.)
Déroulement 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 autant d'associations et de références entre les éléments importés et leurs fichiers que possible.
Tous les éléments importés sont copiés dans les dossiers correspondants de l'Explorateur de solutions. Par exemple, les types de contenu apparaissent dans le dossier Types de contenu et les instances de listes s'affichent dans 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 inclut les modules, formulaires et pages ASPX qui lui sont associés.
É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 informe que les éléments dépendants doivent également être sélectionnés pour que l'importation ait lieu.
En quoi consistent les fonctionnalités ?
Les utilisateurs de SharePoint Designer peuvent voir apparaître des fichiers inattendus, appelés fonctionnalités, dans les solutions importées dans l'Explorateur de solutions. Les fonctionnalités existaient dans la solution SharePoint Designer, mais y étaient masquées. Les fonctionnalités 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, tel que des types de contenu et des définitions de listes, qu'elle contient. Lorsque vous importez votre solution, Visual Studio configure des fonctionnalités pour tous les éléments importés et tente de gérer 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ées 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 parvient pas rapprocher un élément des fichiers dépendants associés. Tous les fichiers que Visual Studio n'a pas pu résoudre apparaissent dans le dossier Autres fichiers importés. De plus, leurs propriétés DeploymentType ont la valeur NoDeployment de façon à ne pas être déployées avec la solution.
Par exemple, si vous importez la définition de liste ExpenseForms, une définition de liste portant ce nom s'affiche dans le dossier Définitions de listes de l'Explorateur de solutions avec les fichiers Elements.xml et Schema.xml associés. Toutefois, les formulaires ASPX et HTML associés peuvent être placés dans un dossier appelé ExpenseForms se trouvant dans le dossier Autres fichiers importés. Pour procéder à l'importation, placez ces fichiers sous la définition de liste ExpenseForms dans l'Explorateur de solutions et remplacez la valeur NoDeployment de la propriété DeploymentType de chaque fichier par ElementFile.
Lors de l'importation de récepteurs d'événements, le fichier Elements.xml est copié dans l'emplacement approprié, mais vous devez inclure manuellement l'assembly dans le package de solution afin qu'il soit déployé avec la solution. Pour plus d'informations sur la procédure à suivre, consultez Comment : ajouter et supprimer des assemblys supplémentaires.
Lors de l'importation de 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 de démarrage dans l'Explorateur de solutions.
Importation de champs et de conteneurs de propriétés
Lorsque vous importez une solution comportant plusieurs champs, toutes les définitions de champ séparées sont fusionnées au sein d'un même fichier Elements.xml, sous un nœud de l'Explorateur de solutions appelé Fields. De la même façon, toutes les entrées de conteneur de propriétés sont fusionnées dans un fichier Elements.xml, sous un nœud appelé PropertyBags.
Dans SharePoint, les champs sont des colonnes d'un type de données spécifié (par exemple, texte, valeur booléenne ou recherche). Pour plus d'informations, consultez Bloc de construction : colonnes et types de champs (page éventuellement en anglais). Les conteneurs de propriétés vous permettent d'ajouter des propriétés à toutes sortes d'objets présents dans SharePoint, tels qu'une batterie de serveurs ou une liste d'un site SharePoint. Ils sont implémentés sous la forme d'une table de hachage de noms et de valeurs de propriétés. Pour plus d'informations, consultez Gestion d'une configuration SharePoint (page éventuellement en anglais) ou Paramètres des conteneurs de propriétés SharePoint (page éventuellement en anglais).
Suppression d'éléments du projet
La plupart des éléments des solutions SharePoint comportent 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. Après l'importation d'une solution SharePoint, Visual Studio ne vous signale pas, tant que vous ne tentez pas de déployer la solution, les problèmes de référence pouvant survenir si vous supprimez un élément de la solution, mais pas ses éléments dépendants. 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 lors du déploiement. L'erreur survient si l'élément dépendant n'est pas présent sur le serveur SharePoint. De même, si un élément supprimé dispose également d'un conteneur de propriétés connexe, supprimez ces entrées de conteneur de propriétés du fichier PropertyBags Elements.xml. Par conséquent, si vous supprimez des éléments d'une solution importée et que vous obtenez des erreurs de déploiement, vérifiez si des éléments dépendants doivent également être supprimés.
Restauration d'attributs de fonctionnalité manquants
Lors de l'importation de solutions, certains attributs de fonctionnalité facultatifs sont omis du manifeste de fonctionnalité importé. Si vous souhaitez restaurer ces attributs dans le nouveau fichier de fonctionnalité, identifiez les attributs manquants en comparant le fichier de fonctionnalité d'origine au nouveau manifeste de fonctionnalité et suivez les instructions présentées dans la rubrique Comment : personnaliser une fonctionnalité SharePoint.
La détection des conflits de déploiement n'est pas mise en œuvre dans les instances de listes intégrées
Visual Studio ne procède pas à la détection des conflits de déploiement sur les instances de listes intégrées (c'est-à-dire les instances de listes par défaut qui sont fournies avec SharePoint). La détection des conflits est mise en œuvre pour éviter le remplacement des instances de listes intégrées dans SharePoint. Les instances de listes intégrées sont quand même déployées ou mises à jour ; toutefois, elles ne sont jamais supprimées ni remplacées. Pour plus d'informations, consultez Dépannage de la création de packages et du déploiement SharePoint.
Importation de flux de travail SharePoint Server 2010
Si vous importez un flux de travail créé dans SharePoint Server 2010, il ne s'exécutera pas correctement après son déploiement. En effet, certains assemblys sont manquants et les flux de travail SharePoint Server 2010 contiennent des formulaires InfoPath qui ne sont pas pris en charge actuellement dans les solutions de flux de travail Visual Studio. Toutefois, les flux de travail SharePoint Server 2010 importés peuvent fonctionner correctement après la correction de certains éléments (par exemple, par l'ajout de références aux assemblys SharePoint Server 2010 et la reconnexion des formulaires InfoPath). Pour plus d'informations, consultez Importation de flux de travail SharePoint Server 2010 (page éventuellement en anglais).
Limite relative au nombre de caractères dans les noms d'éléments
Visual Studio impose une limite de 260 caractères au total pour les noms de projets et d'éléments de projet, y compris le chemin d'accès. Lors de l'importation d'une solution, si un nom d'élément dépasse cette limite, vous obtenez l'erreur suivante :
Le chemin d'accès ou le nom de fichier spécifié, ou les deux, sont trop longs. Le nom de fichier qualifié complet doit comprendre moins de 260 caractères et le nom du répertoire moins de 248 caractères.
Lorsque vous obtenez cette erreur, l'élément n'est pas créé. Ce problème se produit le plus souvent avec les modules importés. Pour éviter ce problème, procédez comme suit :
Utilisez des noms courts pour vos projets lorsque vous les spécifiez dans la boîte de dialogue Ajouter un nouveau projet.
Créez les projets dans un emplacement le plus près possible du dossier racine, de façon à raccourcir le chemin d'accès.
Attribut SharePointProductVersion
Si vous importez une solution créée dans une version antérieure de SharePoint telle que Windows SharePoint Services 3.0 ou Microsoft Office SharePoint Server 2007, remplacez la valeur de l'attribut SharePointProductVersion dans le manifeste du package par 12.0, ou insérez un contrôle ScriptManager dans toutes les pages Web importées et conservez la valeur 14.0 pour SharePointProductVersion. Si vous ne procédez pas ainsi, les formulaires Web importés ne s'afficheront pas dans SharePoint.
Background
Les solutions de SharePoint Foundation 2010 et SharePoint Server 2010 incluent un attribut appelé SharePointProductVersion. SharePoint utilise cet attribut dans ses manifestes de package 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, tandis que la valeur 14.0 indique qu'il est conçu pour SharePoint Foundation 2010 ou SharePoint Server 2010.
Pour garantir une sécurité renforcée lors du rendu des pages ASPX, SharePoint Foundation 2010 et SharePoint Server 2010 exigent que toutes les pages ASPX ou maîtres contiennent un contrôle Script Manager. Pour plus d'informations sur le gestionnaire de scripts, consultez Vue d'ensemble du contrôle ScriptManager. Étant donné que le contrôle ScriptManager n'est pas disponible dans Windows SharePoint Services 3.0 et Microsoft Office SharePoint Server 2007, il convient de l'ajouter à toute page Windows SharePoint Services 3.0 ou Microsoft Office SharePoint Server 2007 qui est mise à niveau vers SharePoint Foundation 2010 ou SharePoint Server 2010. Les pages ASPX qui utilisent une page maître standard ne nécessitent aucun contrôle Script Manager car un contrôle de ce type est déjà 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 ajouter un contrôle de script pour pouvoir fonctionner dans SharePoint Foundation 2010 ou SharePoint Server 2010.
L'absence de contrôle ScriptManager peut s'avérer problématique lorsque vous importez un projet Windows SharePoint Services 3.0 ou Microsoft Office SharePoint Server 2007 dans Visual Studio 2010, étant donné que l'attribut SharePointProductVersion de tous les nouveaux projets a la valeur 14.0. Si vous déployez un projet mis à niveau comportant un Web Form sans gestionnaire de script, le formulaire ne s'affichera pas dans SharePoint.
Voir aussi
Tâches
Procédure pas à pas : importation d'éléments d'un site SharePoint existant
Comment : ajouter un fichier de modèle BDC existant à un projet SharePoint
Autres ressources
Directives pour l'importation de flux de travail réutilisables