Composants du package de solution
Mise à jour : 2008-01-17
In this article:
Solution element
FeatureManifest element
Assembly element
ApplicationResourceFile element
CodeAccessSecurity element
DwpFile element
Resource element
SiteDefinitionManifest element
RootFile element
TemplateFile element
This article discusses the structure of solution packages and provides a description of the solution schema and the elements used within a solution package.
A solution package is the distribution package that delivers your custom Office SharePoint Server 2007 and Windows SharePoint Services 3.0 development work to the Web servers (and possibly to the application servers) in your server farm. Components that can be distributed in a solution package include:
.NET Framework assemblies that wrap the code that drive the solution.
Deployment files such as resource files, images, or other helper files.
Many solutions involve the delivery of new templates and definitions for sites, lists, libraries, fields, content types, and more. These definitions are in the form of CAML-based XML files.
Configurations that must be performed at the Web-server level — for example, the Web.config files for the registration of Web Parts.
In addition, you must include the manifest file to assist Office SharePoint Server 2007 in the deployment process of the solution package. The manifest file contains the list of all assets included in a solution package, along with target locations for these assets and the various configurations in which they must occur. The schema definition for the manifest file is included in the Wss.xsd file that is located in the Office SharePoint Server 2007 system folder.
For more information about solution packages, see Solutions and Web Part packages (https://go.microsoft.com/fwlink/?LinkID=106479&clcid=0x409) in the Windows SharePoint Services 3.0 Software Development Kit (SDK) on MSDN.
Each of the following sections describes each an element of a solution package file.
Solution element
The Solution element is the root element of the manifest file. The SolutionId attribute is an important element of the file that identifies the solution in the solution store (which is part of the configuration database). You identify a solution with a globally unique identifier (GUID) — for example:
<Solution SolutionId="dda6427b-b880-46c0-a428-10c4bac0ce91" xmlns="https://schemas.microsoft.com/sharepoint/" >
</Solution>
DeploymentServerType and ResetWebServer are optional attributes. DeploymentServerType can have two possible values: ApplicationServer or WebFrontEnd. Typically, most of your solutions target the Web servers in your server farm. Examples of solutions that target application servers — for example, index servers, servers running Excel Services, document conversion servers, and so on — are custom configurations or additional custom converters. You can use the IISReset attribute to start a reset of Internet Information Services (IIS) when the solution is deployed to a specific IIS Web application.
FeatureManifest element
Features play an important role in many SharePoint Products and Technologies solutions because they represent the individual components of the solution — for example, a field type, a Web Part, a workflow, and so on. You must represent every Feature that is included in the solution with a FeatureManifest element. The following code example contains the Feature that advertises a Web Part in a SharePoint site:
<Solution SolutionId="dda6427b-b880-46c0-a428-10c4bac0ce91" xmlns="https://schemas.microsoft.com/sharepoint/" >
<FeatureManifests>
<FeatureManifest Location="HelloWorldWebPart_28c3eefe-2c03-4791-9f69-4405c80e1d92\feature.xml" />
</FeatureManifests>
…
</Solution>
When you deploy the solution to a Web server, all of the Feature-related files are copied to the location specified.
Assembly element
Most SharePoint solutions involve one or more .NET Framework assemblies. The Assembly element is used in the manifest file to make the dynamic link library (DLL) available on the destination server. For example:
<Solution SolutionId="dda6427b-b880-46c0-a428-10c4bac0ce91" xmlns="https://schemas.microsoft.com/sharepoint/" >
…
<Assemblies>
<Assembly Location="HelloWorldWebPart.dll" DeploymentTarget="GlobalAssemblyCache" >
<SafeControls>
<SafeControl Assembly="HelloWorldWebPart, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5" Namespace="MSDN" TypeName="HelloWorldWebPart" Safe="True" />
</SafeControls>
</Assembly>
</Assemblies>
</Solution>
The first attribute for the Assembly element is Location, which stores the relative path of the DLL in the solution file. Next, there is the DeploymentTarget attribute, which has two possible values: GlobalAssemblyCache or WebApplication. GlobalAssemblyCache indicates that the assembly should be deployed in the global assembly cache. WebApplication tells Windows SharePoint Services 3.0 to drop the assembly in the private application folder of the IIS Web application. As discussed later, WebApplication implies that the solution that is used depends on the trust level that the administrator sets in the Web.config file that is associated with the IIS Web application. Deploying the assembly in the global assembly cache, which is a fully trusted location, means that as a developer, you do not have to worry about setting this trust level.
The Web Parts in the solution must be registered as safe controls in the Web.config file. The Assembly element can contain one or more SafeControl elements (grouped together in a SafeControls element). Each SafeControl element describes the configuration that must be done in the Web.config file.
Another possible set of child elements of the Assembly element are the ClassResource elements (grouped together in a ClassResources element). Each represents a possible resource that is needed by the deployed assembly. Examples are resource files, XML files, or pictures.
ApplicationResourceFile element
The manifest files can contain one or more ApplicationResourceFile elements with a relative path to a resource file that must be deployed. At the time of deployment, the resource files are copied to the private application resource folder of the IIS Web application. For example:
<Solution SolutionId="8f37f0a7-ec35-4a63-9c3d-91205d9a2ac6"
xmlns="https://schemas.microsoft.com/sharepoint/" >
…
<ApplicationResourceFiles>
<ApplicationResourceFile Location="hellowp.resx"/>
<ApplicationResourceFile Location="hellowp.en-us.resx"/>
</ApplicationResourceFiles>
</Solution>
CodeAccessSecurity element
The CodeAccessSecurity element is important to include in the manifest file when you want to grant specific permissions to your code. In short, the CodeAccessSecurity element has one or more PolicyItem child elements that each define the specifics regarding the code access security policy to apply for the solution. There are two parts for a policy item: the listing of the permissions that are part of it and the assemblies for which these permissions should play a role.
The list of permissions, each represented in an IPermission element, is collected in a PermissionSet element that is the child of the PolicyItem element. Each IPermission element defines a code access security permission that is required for the assembly to run correctly.
One or more Assembly elements can play a role in code access security. You must define them one by one, identifying each by name, version, and full public key.
DwpFile element
Web Parts must be made available in the Web Part gallery before they can be dropped on the Web Part pages. XML files, with either a .dwp extension or a .webpart extension, store the metadata information that is necessary to make the Web Parts available. The solution manifest file can contain one or more DwpFile elements that are collected together in the DwpFiles element, with each pointing to one of these files. For example:
<DwpFiles>
<DwpFile FileName="hellowebpart.webpart" Location="hellowebpart.webpart"/>
</DwpFiles>
Resource element
You can drop resource files in the folder that contains your Feature, and use it from that location. A Resource element represents such a resource in the solution manifest file. The only attribute to set is the relative path in the package to the resource file.
SiteDefinitionManifest element
You use this element when you are deploying a custom site definition. The SiteDefinitionManifest element has a Location attribute that picks up all the files in the specified folder and creates the needed folder in the \12\Template\SiteTemplates folder. The WebTempFile child element deploys the webtemp*.xml file to make the template known to SharePoint Products and Technologies. For example:
<SiteDefinitionManifests>
<SiteDefinitionManifest Location="LitwareSiteTemplate">
<WebTempFile Location="1033\xml\webtempLitware.xml" />
</SiteDefinitionManifest>
</SiteDefinitionManifests>
RootFile element
Solution files can be copied to a specified folder directly under the \12 folder during deployment by inserting a RootFile element in the solution manifest file.
TemplateFile element
The TemplateFile element can be used to define the template files that must be deployed under the \12\Template folder. An example of the type of file you can deploy in this way is the fldtypes*.xml file, which defines the details of a custom field type. Use the Location attribute to specify the relative path to the file.
Download this book
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable books for Office SharePoint Server 2007.
Voir aussi
Concepts
Déployer des personnalisations
Déploiement de personnalisations d’éléments de sites créés
Déploiement des personnalisations d’éléments de sites développés