Site Definitions, Features, and Solutions in Sharepoint Services 3.0

Developers who have used Windows Sharepoint Services 2.0 as a platform to build business solutions have found that working with low-level site definitions provides the greatest amount of control and reusability. A site definition is a directory on the front-end Web server containing XML files and .aspx page templates that define a blueprint for the site, including list schemas and page layouts. The XML-based language that is used inside many site definition files is called Collaborative Application Markup Language (CAML).

However, there are some issues with this strategy in version 2. First, the XML files inside version 2 site definitions were poorly factored, making them unwieldy and hard to work with. Second, there was no support for evolving a site definition once it had been used to create sites. That means there wasn’t a supported technique involving site definitions that could be used to add functionality to an existing Windows Sharepoint Services 2.0 site. Third, site definitions and the custom assemblies they depend on created deployment issues because the files had to be pushed out to each front-end Web server in a farm without any assistance from the Windows Sharepoint Services infrastructure. Finally, Windows Sharepoint Services 2.0 provided no means to localize a site definition, a somewhat frustrating situation for companies wanting to internationalize their business solutions.

The first significant Windows Sharepoint Services 3.0 enhancement in this area is the introduction of features. A feature is like a site definition: a directory containing CAML-based XML files and page templates. But features offer a much more modular approach because you don’t need to define the entire blueprint for a site. Instead, a simple feature can define a single site element such as a custom list definition or menu commands to be displayed in one of the standard Windows Sharepoint Services menus.

Happily, features can be activated on an existing site. For example, you can create a feature that defines a custom list type, an instance of that list type, and an event handler or workflow on that list instance. Once the feature has been installed, it can be activated in any site within a farm and you can activate it through the Windows Sharepoint Services user interface, from the command line, or through custom code written against the Windows Sharepoint Services object model. Once the feature has been activated, the site will include your new custom list and any behavior you want to attach to it.

Features also make developing site definitions simpler. In Windows Sharepoint Services 2.0, each list definition had to be specified inside the context of a site definition. In version 3 every list definition can be factored out into its own feature. Site definitions are now easier to create as they can be composed using feature references. This is the approach taken with all the list types that ship as part of Windows Sharepoint Services collaboration services.

Windows Sharepoint Services 3.0 introduces a new deployment mechanism called a solution that is similar to Web Part packages in the sense that it is an aggregate .cab file containing XML instructions and files that need to be deployed on each front-end Web server. However, solutions go beyond Web Part packages to support the deployment of features, site definitions, and related assemblies used for event handlers and workflows.

Windows Sharepoint Services 3.0 support for solutions also assists in pushing deployment files to each Web server in a farm. An administrator adds a solution to a Windows Sharepoint Services farm, which copies the solution .cab file into the configuration database. Next, the administrator runs a command to deploy the solution, at which time Windows Sharepoint Services starts a timer job to push the solution .cab file out to each Web server and install it.

A very welcome change for Windows Sharepoint Services developers is the new support for localization. This functionality has been built on top of the localization infrastructure of ASP.NET 2.0, and it’s now possible (and recommended) to create site definitions and features in a language-neutral fashion and to maintain string literals in .resx files. Within the XML files and .aspx page template files of a feature or site definition you can acquire the value for a named string that has been localized into a .resx file using standard ASP.NET syntax.

<%$Resources:Litware,MyString%>