Création manuelle d’une solution
Dernière modification : mercredi 13 avril 2011
S’applique à : SharePoint Foundation 2010
Cette rubrique fournit des informations de base sur les packages de solution et sur la façon de les créer manuellement.
Important
Visual Studio comprend des outils qui simplifient (et automatisent en grande partie) la création et la configuration de packages de solution. Nous vous recommandons de recourir à ces outils. Utilisez uniquement cette rubrique si vous avez besoin d’informations de base, si vous avez besoin de modifier l’un des fichiers en dehors des outils Visual Studio (ce qui est rare) ou si vous êtes un développeur et que vous ne possédez pas Visual Studio.
Packages de solution
Un package de solution est un fichier CAB avec une extension de nom de fichier .wsp. Il comprend toujours un fichier manifeste et peut également contenir une partie ou la totalité des composants suivants :
Définitions de sites (onet.xml, webtemp*.xml et éventuellement default.aspx)
Des stratégies de sécurité d'accès
Modifications apportées à web.config
Fichiers de modèle et fichiers racine, qui peuvent inclure :
Pages d’application (*.aspx)
Ressources (*.resx)
Fichiers de ressources (par exemple, *.doc ou *.xls)
Contrôle utilisateur (*.ascx)
Assemblys non-SharePoint (par exemple des bibliothèques de classes managées personnalisées). Ceux-ci peuvent être déployés conjointement avec les éléments suivants :
Entrées de contrôle sécurisées
Ressources
Définitions des fonctionnalités avec leurs définitions et fichiers d’élément correspondants. Une fonctionnalité peut notamment comprendre ce qui suit :
Fichiers WebPart (*.webpart, *.dwp)
Instances de liste et modèles de liste
Types de contenu et types de champ personnalisés
Modèles BCS/BDC
Récepteurs d’événements
Pages de site (*.aspx)
Assemblys pour des composants WebPart ou d’autres classes SharePoint Foundation personnalisées. Ceux-ci peuvent être déployés conjointement avec les éléments suivants :
Entrées de contrôle sécurisées
Ressources
Les fichiers de solution ont une structure hiérarchique (un fichier manifeste se trouve à la racine), tandis que les répertoires de définitions de fonctionnalités, de ressources ou de sites sont contenus dans des sous-répertoires.
Les fichiers d’une définition de fonctionnalité ou de particulière doivent être placés dans le sous-répertoire de la définition de cette fonctionnalité ou de ce site.
Notes
La structure de répertoires à l’intérieur du fichier .wsp détermine la structure de répertoires finale sur le système de fichiers du serveur Web frontal. Mais en général, la structure de répertoires dans l’Explorateur de solutions, qui est générée par les outils de Visual Studio, ne correspond pas exactement à la structure de répertoires du serveur Web frontal.
Pour créer manuellement un package de solution, procédez comme suit :
Créez un fichier manifest.xml de solution
Le fichier manifeste de solution (toujours appelé manifest.xml) est stocké à la racine d’un fichier de solution. Ce fichier définit la liste des fonctionnalités, des définitions de site, des fichiers de ressources, des fichiers de composant WebPart et des assemblys à traiter. Il ne définit pas la structure de fichiers ; si des fichiers sont inclus dans une solution, mais qu’ils ne sont pas répertoriés dans le fichier manifeste XML, ils ne sont pas traités.
La structure ci-dessous illustre la structure d’un fichier manifest.xml.
<Solution SolutionId="4AFC1350-F354-4439-B941-51377E845F2B" xmlns="https://schemas.microsoft.com/sharepoint/"> <FeatureManifests> <FeatureManifest Location="FeatureLibrary\feature.xml"/> </FeatureManifests> <TemplateFiles> <TemplateFile Location="ControlTemplates\Featurelibraryform.ascx"/> </TemplateFiles> <RootFiles> <!-- These files go into the 12\ directory and can be used for Web services and global resources --> <RootFile Location="ISAPI\MyWebService.asmx"> </RootFiles> <Assemblies> <Assembly DeploymentTarget="GlobalAssemblyCache" Location="ms.samples.sharepoint.myFeature.dll"/> </Assemblies> </Solution>
En outre, vous pouvez ajouter un élément DwpFiles pour spécifier les fichiers .webpart ou .dwp, ou un élément ResourceFiles pour spécifier les fichiers de ressources, les définitions de site, les ressources d’application et les stratégies de sécurité d’accès au code.
Si le package comprend des fonctionnalités, chacune d’entre elles possède un fichier feature.xml. Pour chaque fichier manifeste d’élément de fonctionnalité (elements.xml) dans la fonctionnalité, ajoutez une balise ElementFile qui pointe vers le manifeste d’élément de fonctionnalité.
Créez le package de solution (fichier .wsp).
Étant donné que le fichier de solution est essentiellement un fichier .cab, utilisez l’outil makecab.exe pour créer le package de solution. Cet outil prend un pointeur vers un fichier .ddf (Diamond Directive File), qui décrit la structure du fichier .cab. Le format d’un fichier .ddf est pratiquement du même style que le fichier .inf ; vous déclarez un en-tête standard, puis vous énumérez, un fichier par ligne, le jeu des fichiers en fonction de leur emplacement sur le disque, séparés en fonction de leur emplacement dans le fichier .cab.
; .OPTION EXPLICIT ; Generate errors .Set CabinetNameTemplate=MySolutionFile.wsp .set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory .Set CompressionType=MSZIP;** All files are compressed in cabinet files .Set UniqueFiles="ON" .Set Cabinet=on .Set DiskDirectory1=Package build\manifest.xml manifest.xml build\ MySolutionFile \feature.xml MySolutionFile \feature.xml ...