Background:

Anyone who is familiar with development & deployment of custom solutions on SharePoint Portal Server 2003 or Windows SharePoint Services will probably agree when I say there are certain areas lacking in the end to end process.

For example, here is a high level generic step by step process that usually happens:

1. Spec written (some people seem to think this step is optional)
2. Developer develops code etc... Usually on a stand-alone, single server SharePoint environment. (I personally use a VPC for all development these days)
3. Developer packages code into an installer if you are lucky
4. Testing
5. Hand off to production people who go and install it on the server(s).

This would normally be really easy right? Well, in SharePoint land there are many areas where "things" need to be done during an installation. Some of these are (but not limited to):

• Assembly deployment. GAC or BIN
• Web.config changes. Additions to the safe controls list, CAS security policies,
• Resource files like images,
• Dwp files
• Site definitions (list definitions etc...)
• ...

Depending on how your development team packaged these would depend on how much work you had to do to deploy them.

To make matters worse, depending on your physical SharePoint farm you might need to do install steps on each server. This brought in complexity around what servers had what versions at what time etc... A nightmare if you were managing a large farm with many servers.

How we make this better in MOSS and WSSv3:

In MOSS we have a good solution to all of this called the Solution Framework. Here is a little summary about what this is:

"The Windows SharePoint Services (WSS) solution framework provides a way to bundle together all of the components for extending SharePoint in a new file called a solution file (a CAB-based format with a WSP extension). A solution is a deployable, reusable package that can contain a set of features and site definitions, templates, Web Parts, and assemblies that you can apply to a site, and individually enable or disable." – WSS SDK

Not only this but the Solution Framework takes care of deploying the solution to ALL front end web servers in the farm without the admin having to go to each box to do this manually!

You can:

• Deploy the Solution package to the farm
• Retract the Solutions package
• When a new web server is added, automatically deploy the solution to it
• Deploy new versions of the Solution

Practical example:

In the system I talked about in "Application Development on MOSS & WSSv3" we are using a Solution package to deploy:

• A custom Site Definition
• 6 Feature Definitions (another new MOSS technology) that are:
  • Custom Workflows x2
  • Timer Job
  • Content Type
  • Custom List definition
  • Custom Site Columns definition
• Web part
  • SafeControls list entry

Note: I won't talk about Features or how to create them; Todd has a good post on that subject here: http://www.sharepointblogs.com/tbaginski/archive/2006/06/02/8062.aspx

[Updated] This means when we want to deploy this solution to a new farm we simply use the STSADM -addsolution -filename <path to solution file here> to upload the solution to the farm.  Once uploaded you can simply to into the "Solution management" section under the "Operations" tab in the Central Administration Site, and deploy that solution.

Once it is uploaded we can then choose to Deploy that solution.

This gives you options on when you want the deployment to take place and to what web applications. (In the shot above I had an assembly being deployed to the GAC, hence the warning)

Although all this will be/is documented in the WSS SDK, I thought I quickly go over how to make a solution file.

Consists of:

• A CAB file containing
  • A Manifest.xml file
  • All the files for the Features etc... that make up your solution

Below is a cut down sample XML manifest.xml file for the example I used above (highlighted text is comments):

<?xml version="1.0" encoding="utf-8" ?>
<Solution xmlns="http://schemas.microsoft.com/sharepoint/" SolutionId="{79d1a62e-3627-11db-963e-00e08161165f}" ResetWebServer="TRUE">

    <Assemblies>
        <Assembly DeploymentTarget="GlobalAssemblyCache" Location="Foo.Sharepoint.Webparts\Foo.SharePoint.WebParts.dll">
            <SafeControls>
                <SafeControl Assembly="Foo.Sharepoint.Webparts, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=63cce650e8605f5d" Namespace="Foo.Sharepoint.Webparts" TypeName="*"/>
            </SafeControls>
        </Assembly>
        <Assembly DeploymentTarget="GlobalAssemblyCache" Location="Foo.Sharepoint.Timer/Foo.Sharepoint.Timer.dll"/>
    </Assemblies>

    <FeatureManifests>

        <FeatureManifest Location="Foo.Sharepoint.Timer\Feature.xml"/>

        <FeatureManifest Location="Foo.CustomType\Feature.xml"/>

        <FeatureManifest Location="Foo.FooLibrary\Feature.xml"/>

        <FeatureManifest Location="Foo.Columns\Feature.xml"/>

        <FeatureManifest Location="Foo.Workflow.ProcessFoo\Feature.xml"/>

        <FeatureManifest Location="Foo.Workflow.ProvisionFoo\Feature.xml"/>

    </FeatureManifests>

    <SiteDefinitionManifests>
        <SiteDefinitionManifest Location="FOO">
            <WebTempFile Location="1033\XML\WEBTEMPFoo.XML"/>
        </SiteDefinitionManifest>
    </SiteDefinitionManifests>
</Solution>

Then you package this up along with all your Feature files into a CAB file with a ".wsp" extension. In short each feature goes into a sub-dir in the CAB that matches the path you have in the Manifest.xml file.  You can use cabmake.exe to do this, or any other tool you like.

Then you are ready to go and deploy!

Although this is probably a little more work to begin with, your deployment team will thank you for it immensely.

-Chris.