Virtual Developer Workshop: Containerized Development with Docker
Introduction: Defining the Snag in SharePoint 2003
Microsoft SharePoint 2003 (WSS and SPS) was the first version of SharePoint with a consistent and powerful realization of an Application Programming Interface (API) based in the Microsoft DotNet Framework. Creating the possibility of developing customizations for SharePoint has always been a hot item in the programming world. However, deploying the customizations made for the 2003 version has proven to be a frustrating issue in the reception of the system by the technical community. Truth be said, there is no official method of deploying custom software for SharePoint 2003. The developer has two time-consuming options: an awkward manual "copy and paste" of all the customized files and assemblies, or alternately, fabricating a custom-built installer.
The SPS 2003 customizations, which created a stir when they came out, consisted of new templates, some of them including many files; assemblies to install in the local IIS directory or in the Global Assembly Cache (GAC); custom aspx pages; Event Handlers; WebParts; Web Controls and Web Services. Of these, WebParts was the only component with an efficient, well-established installation procedure (using the "stsadm" tool, the command line administration tool of SharePoint); nevertheless, if the WebPart needed to be installed within a template, this useful deployment procedure became more complicated.
Additional problems inherent in the long-standing deployment system were the lack of a versioning scheme, the inability to recover information or revert to the pre-deployment situation in an easy and consistent manner, and the difficulty in installing all the components in the server farm in a unified way (the deployment needs to be repeated in each independent server of the farm). Equally, the responsible individuals were required to make changes in the web.config file to ensure the registration of components and configuration for the Computer Access Security (CAS) policies.
SharePoint 2007 Solutions: Tackling the Problem
The latest version of SharePoint, Windows SharePoint Services (WSS 2007) and Microsoft Office SharePoint Server (MOSS 2007), has offered a resolution to the deployment problem with the introduction of SharePoint Solutions.
SharePoint Solutions is a framework that assembles all the components necessary to compose a customization in one Solution file, which then can be distributed in an effortless way. The framework allows for the installation, activation, deactivation, and removal actions to be employed by system administrators, without their involvement in the technical issues relative to the physical localization of files and assemblies.
In one skillful sweep, SharePoint Solutions provides for:
- Compilation of all customization components (aspx files, DLLs, resource files, definition files, and so forth) in one file
- Physical installation of the components in the farm without activation: The solution can be copied to all the servers in the farm without being activated
- Activation in a timetabled way: The system administrator can decide when the customizations will be activated automatically
- A versioning system that is able to install versions of the same customizations
- If a new server is added to the farm, the Solutions Framework ensures the installation of the customization automatically, without intervention from the system administrator
- Deactivation of the customization, allowing for a return to the original situation, also in a scheduled way
- Physical de-installation of the components to remove them from the servers
In essence, a Solution file is a .cab comprised file that contains all the files to be installed as well as a "manifest.xml" file. The manifest file is a description for the solutions engine to define its tasks, the physical localization to install the custom files, and some metadata necessary for its registration in SharePoint. The extension for Solution files is ".wsp", and if the extension is changed to ".cab", it's possible to open the file and examine its contents.
Microsoft, as a company strategy, is also taking advantage of SharePoint Solutions to distribute the latest in software for SharePoint; the new "Windows SharePoint Services 3.0 Application Templates: Server Admin Templates" uses an "Application Template Core" main application that installs an administration tool for the templates and which then is installed as a Solution. As an additional feature, all the templates are distributed as Solutions as well.
Using Solutions from the User Interface and stsadm
To install a Solution, use the "stsadm" SharePoint administrators' tool, with the following syntax:
STSADM.EXE -o addsolution -filename <Path to the wsp file>
For example, to install the above-mentioned core application for the templates, this is the form:
"C:\Program Files\Common Files\Microsoft Shared\ web server extensions\12\BIN\STSADM.EXE" -o addsolution -filename C:\ ApplicationTemplateCore.wsp
(if the .wsp is at the root of the file system)
After installation, the Solution is uploaded to the configuration DataBase (the "Objects" table of the "Config" database), but in this form it is not ready to be used in the system; it still needs to be activated. From this point forward, the handling of the Solution can be done from the Central Administration Web interface of SharePoint. Go to the Central Administration, the "Operations" tab, and under "Solution management" (section "Global configuration") a list with all the installed solutions can be found, together with its status and which Web Application(s) have been deployed.
Figure 1: Solution Management web page in the Central Administration of SharePoint
When the desired Solution is selected on the page, the next screen will show a summary of the Solution plus two buttons: one to Deploy the Solution and one to Remove it. The second button will reverse the installation procedure and the first will finish the installation process.
Figure 2: Web page to Deploy or Remove a Solution
Deploying can be completed immediately or at any determined timeframe in the future. The Solution Framework can initiate a scheduled task; in this way, you can deploy the Solution when the system administrator considers it appropriate.
The metadata in the Solution definition or in each component determines the scope of the deployment in the farm. The example shown in Figure 3 illustrates a global deployment and because one or more assemblies are deployed in the GAC, the page displays a warning.
Figure 3: Deployment screen in the Central Administration
Deployment using the "stsadm" tool is also possible with the subsequent syntax:
STSADM.EXE -o deploysolution -name <Name of the Solution> [-url <Virtual Server URL>] [-allcontenturls] [-time <Time to Deploy at>] [-immediate] [-local] [-allowgacdeployment] [-allowcaspolicies] [-lcid <Language>] [-force]
Note: The parameters between "" are not obligatory.
Versioning of Solutions is possible if a Solution is deployed with the same solution ID of an existing Solution in the Store. In this case, the original Solution is removed from the Store, backed up and saved in the configuration Store, and the new Solution is added. The Backup is referred to in the event of an installation failure, and only one Backup is stored for each Solution.
After deployment, the Solution can be "Retracted" (deactivated) and removed by following the inverse procedure from the Central Administration's user interface or using "stsadm" with the syntax:
STSADM.EXE -o retractsolution bo?=name <Name of the Solution> [-url <Virtual Server URL>] [-allcontenturls] [-time <Time to Remove at>] [-immediate] [-local] [-lcid <Language>]
As observed in the parameters list of "deploysolution" and "retractsolution", "stsadm" offers better control than the Web user interface. However, the downside is that it is a command line tool that is less user-friendly.
To delete the Solution from the farm, simply apply:
STSADM.EXE -o deletesolution -name <Name of the Solution> [-override] [-lcid <Language>]