Provisioning a solution to a SharePoint server can be done using several methods, however the only correct methods are to use templates and solution packages. In my series of posts on provisioning, discussed the relevance of provisioning, if this is your first article you are reading, I would suggest looking at Overview of features, templates, site definitions, solutions in SharePoint and SharePoint - Overview to creating a Solution Package.
Now, remember WSS is a powerful provisioning engine and is geared up to deploy web sites and components. These can be deployed to a single or multiple servers in a web farm with ease. Provisioning is easy once you get to grips with the WSS provisioning engine, the most important thing is follow the rules and you will not have issues deploying to SharePoint. I strongly urge you to master this deployment mechanism especially solutions and solution packages, it is not conventional deployment as it is geared to SharePoint.
After you have created the content of your new SharePoint functionality, that is features, web parts, assemblies, pages, resources etc; you will have to register them into a solution manifest file. The manifest file is an xml file that follows the CAML schema and has a <Solution...> root element. When the solution is deployed using a package, SharePoint will open up the .wsp file looking for this solution manifest. It will then proceed to extract and register everything in the solution manifest.
The basic schema of a solution manifest
<Solution
DeploymentServerType = "ApplicationServer"
ResetWebServer = "TRUE"
SolutionId = "GUID">
<ApplicationResourceFiles />
<Assemblies />
<CodeAccessSecurity />
<DwpFiles />
<FeatureManifests />
<Resources />
<SiteDefinitionManifests />
<RootFiles />
<TemplateFiles />
</Solution>
The attributes are
| DeploymentServerType |
| |
Optional. Default=WebFrontEnd. This attribute indicates the target of your solution to either a web front end server (WebFrontEnd) or an application server (ApplicationServer).
|
| ResetWebServer |
| |
Optional. Default=FALSE. Indicates a boolean value whether the web server needs to be reset after the solution is deployed. |
| SolutionId |
| |
Required. A globally unique identifier that should be created for the solution. Each solution should have its own unique GUID. |
What can be deployed using a solution manifest
| Application Resource Files |
|
In order to globalise your solution and templates, you will need to create resource files for each localised language. These resource files should be placed into the 12\Resources directory. Using a solution, you will be able to deploy these resources files.
Note that the resorce files are globally available to the entire application across different servers and web applications.
The basic schema for the ApplicationResourceFiles element is shown below
<ApplicationResourceFiles>
<ApplicationResourceFile Location="Text"/>
.
.
</ApplicationResourceFiles>
|
| Assemblies |
| |
The most useful thing about a solution is that it can deploy your assemblies into either the local bin folder of a site that uses the assembly or it can register the assembly in the Global Assembly Cache (GAC). Now for the infomercial, "However when you buy into this concept; the provisioning engine will allow you to automatically register these assemblies as SafeControls ... absolutely for free" . It is simply done by putting a <SafeControl> element in the manifest and it will be done.
Again this will be deployed onto all servers in a web farm making your assembly available on all servers, and automatically registered in all servers web.config files.
The basic schema for the Assemblies element is shown below
<Assemblies>
<Assembly
DeploymentTarget = "GlobalAssemblyCache"
Location = "Text">
<SafeControls>
<SafeControl
Assembly = "Text"
Namespace = "Text"
Safe = "TRUE"
TypeName = "Text"/>
...
</SafeControls>
<ClassResources>
<ClassResource
FileName = "Text"
Location = "Text">
</ClassResource>
...
</ClassResources>
</Assembly>
.
.
</Assemblies>
|
| Code Access Security |
| |
By default, assemblies deployed into the bin folder are sandboxed with a very restrictive trust level. You will need to define the appropriate trust level of your assembly especially if you access local resources or play with the WSS object model. Should you not do this your assembly will fail in a production environment.
The basic schema for the CodeAccessSecurity element is shown below
<CodeAccessSecurity>
<PolicyItem>
<PermissionSet ....
...
</PermissionSet>
<Assemblies>
<Assembly ...
...
</Assemblies>
</PolicyItem>
</CodeAccessSecurity>
|
| Dwp Files |
| |
There are a number of ways to deploy a web part, however the recommended way is to use a solution package. You will have to specify the location of the .webpart files in the DwpFile element. also include your assemblies and resource files into the solution. The best part about a solution is that the assemblies can be deployed to all servers in the farm as well as registered as a safe control.
The basic schema for the DwpFiles element is shown below
<DwpFiles>
<DwpFile
Location= "Text">
</DwpFile>
...
</DwpFiles>
Note that the SharePoint SDK indicates FileName instead of Location which is incorrect.
|
| Feature Manifests |
| |
Typically a solution will contain many different features, all these features can then be activated together to form part of a bigger system or solution you are deploying. You may have a feature for your site columns and content types, different features for different web parts and then even different features for lists and list templates.
It is important to not and often I get many questions around this : A solution can install many features into the 12 hive, however the opposite is not possible. Remember that a solution is a deployment unit and will copy over all your features, these features can then be activated either manually or through templates.
The basic schema for the Featuremanifests element is shown below
<FeatureManifests>
<FeatureManifest
Location="Text"/>
</FeatureManifests>
|
| Resources |
| |
Should you wish to localise a feature, you can install a resource file into the features folder. It is preferable that you localise the file using the <Resource> element instead of using a the <RootFile>. The resource will be deployed to 12\TEMPLATE\FEATURES\<featurename> folder.
The basic schema for the Resources element is shown below
<Resources>
<Resource
Location="Text"/>
...
</Resources>
|
| Site Definition Manifests |
| |
The really cool thing about a solution is deploy all you site definitions and these site definitions will be used by administrators and users to create sites. Remember that the site definition will then activate needed features, provision pages and menus and place web parts onto site pages.
The basic schema for the SiteDefinitionManifests element is shown below
<SiteDefinitionManifests>
<SiteDefinitionManifest
Location="Text">
<WebTempFile
Location="Text">
</SiteDefinitionManifest>
...
</SiteDefinitionManifests>
|
| Root Files |
| |
The root file element allows you to copy over any other file, such as images, style sheets, controls. The root files element will copy files relative to the 12 hive.
The basic schema for the RootFiles element is shown below
<RootFiles>
<RootFile
Location = "Text">
</RootFile>
...
</RootFiles>
|
| Template Files |
| |
The Template Files element is similar to the root element, however it will allow you to target files to the 12\TEMPLATE folder.
The basic schema for the ApplicationResourceFiles element is shown below
<TemplateFiles>
<TemplateFile
Location="Text"/>
...
</TemplateFiles>
|
Location attribute
Many of the child elements in the solution package include a Location attribute, this location is the location of the file within the solution package (.wsp) file. In a future post I will walk you through the steps to create a .wsp file, however it is a standard cabinet file and when you open the cabinet the root directory of the cabinet is displayed.
Example
The RSSView web part is in a folder FEATURE\GroundingRSS in the .wsp file. You would specify the location of the <DwpFile element as FEATURES\GroundingRSS\RSSView.webpart
See also