WSP and WSPBuilder --- Penicillin in the life of a SharePoint Developer!!!

SharePoint Solution Package AKA WSP

The Windows SharePoint Services solution framework provides a way to bundle all the components for extending Windows SharePoint Services in a new file that is called a solution file. A solution file has a .CAB-based format but a .WSP extension. A solution is a deployable, reusable package that can contain a set of Features, site definitions, and assemblies that apply to sites, and that you can enable or disable individually. You can use the solution file to deploy the contents of a Web Part package, including assemblies, class resources, .dwp files, and other package components.

Benefits of the Solution Framework
The solution framework provides the following advantages:
1. A unified infrastructure for deploying solutions.

2. Integrated deployment.

a. Deploy new solutions and upgrade existing solutions across the farm.

b. Synchronize a front-end Web server so that its state is consistent with the state of other servers in the farm.

What a WSP can contain?
A solution package is a cabinet (.cab) file with a .wsp file name extension and a manifest file. It can contain the following components:
1. Site definitions
2. Feature definitions and their corresponding element definitions and files
3. Web Part files (*.webpart, *.dwp)
4. Template files and root files, which can include the following:
a. _layouts files
b. Resources (*.resx)
c. Resource files (for example, *.doc or *.xls)
5. Assemblies, which can include the following:
a. Safe control entries
b. Resources
6. Code access security policies

Solution files have a hierarchical structure—a manifest file is at the root—while feature, resource, or site definition directories are contained in subdirectories. In turn, feature definitions define where associated files are located inside of the solution.
The solution creator can define the remaining structure; however, it is recommended that files for a particular feature or site definition be placed in that feature or site definition's subdirectory.

What is a solution manifest.xml file ?

The solution manifest (always called manifest.xml) is stored at the root of a solution file. This file defines the list of features, site definitions, resource files, Web Part files, and assemblies to process. It does not define the file structure—if files are included in a solution but not listed in the manifest XML file, they are not processed in any way.
Following is the structure of a manifest.xml file -

What is a solution feature.xml file ?

Features reduce the complexity involved in making simple site customizations, and are robust when upgrades are applied to a deployment. Features eliminate the need to copy large chunks of code to change simple functionality. Features thus reduce versioning and inconsistency issues that may arise among front-end Web servers. Features make it easier to activate or deactivate functionality in the course of a deployment, and administrators can easily transform the template or definition of a site by simply toggling a particular Feature on or off in the user interface.
Features provide the following capabilities:
1. Scoping semantics for determining where custom code runs
2. Pluggable behavior for installing or uninstalling Features within a deployment
3. Pluggable behavior for activating or deactivating Features at a given scope
4. A scoped property bag for storing data required by a Feature within its scope
5. The basis of a unified framework for distributed deployment of Windows SharePoint Services solutions

Feature Implementation
To implement a Feature you add a subfolder containing a Feature definition within the Features setup directory (Local_Drive:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES). The Feature subfolder includes a Feature.xml file that defines the base properties of the Feature and lists elements bound to it, such as XML files containing element manifests and any other supporting files. A Feature folder may contain only a Feature.xml file, or it may contain a Feature.xml file and any number of supporting element files, including XML files, but also .aspx, .htm, .xsn, .resx, .dll, and other file types.
Following is the structure of a feature.xml file -

Note:
When you create a folder within the Features directory through Windows Explorer by right-clicking a folder, pointing to New, and then clicking Folder, the new folder does not have inherited permissions. If you deploy a Feature in the folder, then some Windows SharePoint Services pages, such as for site settings or list views, throw an exception. You can fix this problem by right-clicking the new folder, click Properties, click Security, and then click Advanced. On the Permissions tab, delete uninherited permissions from the folder. You can also fix this problem by creating the new folder at the command prompt through the md command.

After creating the Feature folder, you can install and activate the Feature through command-line operations of stsadm.exe, or through the object model. You can also activate a Feature through the user interface. Installing a Feature makes its definition and elements known throughout a server farm, and activating the Feature makes the feature available at a particular scope.

What is a solution elements.xml file ?
Elements.xml is referred via Feature.xml. Here, Module URLs are targets within MOSS; File URLs are relative to the Module URL. Following is the structure of a feature.xml file -

So, after the basics of WSP, we need to learn WSPBuilder...

You can download it from the following link -
http://www.codeplex.com/wspbuilder

A very good documentation cum tutorial can be found from -
http://www.zimmergren.net/archive/2009/04/08/wspbuilder-walkthrough-of-the-visual-studio-add-in.aspx

So, before ending this post lets summarize the whole thing in novice statements -

Manifest.xml: Instructs SharePoint where to deploy the files held in the cabinet. File paths depend on the containing XML element: assembly paths are relative to the target /bin directory, TemplateFiles are relative to the 12-hive's TEMPLATE directory, DwpFiles are relative to the wwwroot\wss\VirtualDirectories\wpcatalog directory, and FeatureManifests and Resources are both relative to the 12-hive's TEMPLATE\FEATURES directory.

Feature.xml: ElementFile locations are relative to the directory structure where the feature is installed (eg. as specified in Manfiest.xml)

Elements.xml (via Feature.xml): Module URLs are targets within MOSS; File URLs are relative to the Module URL