Working with Packages Share Point 2010

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 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.

  1. Create a new blank site .
  2. Using Visual Studio, create a new Empty SharePoint Project named, as shown:
  3. Package Designer

  4. 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.
  5. Choose Project Add New Item. Then in the Add New Item dialog, select Empty Element, as shown. Name the element FirstElement.
  6. project designer

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:

project designer

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:

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
When adding assemblies to a solution, we can also add a safe control entry. Safe control entries were mentioned in preceding chapters, but I’ll clarify exactly what they are and why you might need them here.

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.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Share Point 2010 Topics