What may not be apparent in
the projects that we’ve created so far is that when we’re deploying a
solution to SharePoint, the artifacts in our Visual Studio project are
collated into a package file that is then copied to the server. The
SharePoint deployment process then uses the contents of the package to
install our customization. We can see this process in action by
monitoring the output window in Visual Studio.
So far we’ve been working on a
single server development machine, but what happens if a farm includes
several servers? How can we deploy our customization to all servers? The
answer is, of course, to use a package that can be stored centrally and
automatically rolled out to all servers in the farm as part of the
installation process. As new servers are added to the farm, centrally
stored packages are automatically deployed as required. Furthermore,
farm administrators have the ability to deploy and retract packages from
the Central Administration console.
Package Structure
SharePoint
packages are created as cabinet (CAB) files with a .wsp extension. We
can, however, rename a .wsp file, such as myproject.wsp, to
myproject.cab and view the contents in Windows Explorer.
Each package file contains many different elements,
mostly consisting of XML files and resources such as dynamic link
libraries (DLLs), script files, or images. One thing that package files
have in common, however, is a manifest.xml file. This file is basically
the setup guide for the package and contains a list of the deployable
items within the package.
Each solution consists of one or more deployable
item. A number of different types of deployable items exist, such as an
assembly, a resource file, or a site definition file. However, for the
most part, deployable items are defined using feature manifests.
Package Designer
Let’s see how these ideas jibe with our understanding of the Visual Studio project structure.
Create a new blank site named Example 19.
Using Visual Studio, create a new Empty SharePoint Project named Exmaple19, as shown:
In
the SharePoint Project Wizard, set the site to use for debugging as the
site created in step 1, and then select the Deploy As Farm Solution
option.
Choose Project Add New Item. Then in the Add New Item dialog, select Empty Element, as shown. Name the element FirstElement.
Let’s take a look at what’s happened in Visual
Studio. We have a Features folder and a Package folder. If we
double-click Package.package within the Package folder, we’ll see the
package designer shown here:
The
package designer gives us a visual tool we can use to modify the
manifest.xml for a package file. Click the Manifest button at the bottom
of the page to see the underlying manifest.xml file:
<Solution xmlns="http://schemas.microsoft.com/sharepoint/"
SolutionId="--snipped--" SharePointProductVersion="14.0">
<Assemblies>
<Assembly Location="Example19.dll"
DeploymentTarget="GlobalAssemblyCache" />
</Assemblies>
<FeatureManifests>
<FeatureManifest Location="Example19_Feature1\Feature.xml" />
</FeatureManifests>
</Solution>
In this manifest are two deployable items: an
assembly that will be the build output of our Visual Studio project and a
FeatureManifest that points to a Feature.xml file.
Deploying Assemblies
By default, the build output assembly will always be
added to the solution file. This means that any code that we add within
our project will be compiled and the resultant DLL will be deployed to
SharePoint in the solution package. In some situations, however, we may
need to add another assembly. By clicking the Advanced button in the
Solution Designer, we can either add an assembly or add the compiled
output of another project within the solution. Along with adding
additional assemblies, we can also add any resource assemblies that
should be included.
Adding Safe Controls
SharePoint makes use of a custom page parser to assemble the user interface, and this parser is known as the Safe-Mode Parser.
Its primary function is to prevent users from executing code on the
server that hasn’t been specifically approved by an administrator. The
mechanism by which an administrator approves code for execution is the
SafeControl entry, which is ultimately applied as a web.config entry on
each front-end server. If our assembly contains user controls or web
parts or any other component that can be declaratively added to a page, a
SafeControl entry is required. If a user attempts to add a component
that does not have a corresponding SafeControl entry, an error will be
thrown detailing the absence of the SafeControl entry as the problem.
