SharePoint 2010 Development

SharePoint 2010 Development - Customizations and Deployment

This video will give you insights how customizations are put into solutions and features and how they are deployed to SharePoint


Video Transcription

This presentation will give you insights how customizations are put into solutions and features and how they are deployed to SharePoint.

Please make sure you have seen the video ‘Development Overview’ explaining things like SharePoint applications, APIs, tools and why we need things like ‘Solutions’ and ‘Deployment’.

Because of the differences between ASP.NET and SharePoint the concept of ‘Solutions’ and ‘Deployment’ are part of your daily work when you extend SharePoint.

If you remember the following graphic you see that ‘Solutions’ and ‘Deployment’ only applies to SharePoint applications using the Server OM.

Client Applications using the Client OM or Web Services can be installed like other Windows applications using an installer so the following concepts don’t apply.

File System

But before we are going to learn about solutions and deployment it’s important to understand where SharePoint is installed on the file system. If you plan to add new functionality you will need to place them somewhere on the file system. On the one hand it’s good to know where things go and on the other hand you may want to group custom files using a folder and naming conventions.

With the file system in mind you get a much better understanding of the things that happen during development and deployment.

There are different SharePoint folders which are created on every SharePoint Server. There are also different databases used to store configuration data which exists at the same time on the file system. While SharePoint handles everything regarding the database you can influence file- and folder names of your customization. And you should take advantage of that.

This demo shows you:

  • Folders where SharePoint is installed and where files will be placed in order to extend SharePoint.


If you implement a Web Part you have different files which are copied to different folders. The Web Part Feature, Web Part Definition (.webpart) and the Elements.xml file are copied to the features folder. The Assembly is placed in the Global Assembly Cache. Images are stored under the Images folder.

SharePoint comes with a solution framework you need to use since you need to:

  • Deploy new components and upgrade old ones across different databases, servers and folders.
  • Synchronize all servers in your SharePoint farm so you can keep their state consistent. If you add a new server to the SharePoint farm the solution will be automatically deployed to the new server.


Therefore you need to package all your customizations in a file called solution package. This file is a CAB file with a .wsp extension. If you rename the extension to .cab you can browse the file.

The Solution Framework supports 2 types of solutions: Farm Solutions and Sandboxed Solutions. Farm Solutions will be discussed here since they are supported in SharePoint 2007, 2010 and 2013 whereas Sandboxed Solutions appear in SharePoint 2010 and are of less importance in SharePoint 2013. Sandboxed Solutions will be discussed later in their own video.

Farm Solutions allow you to interact with the whole SharePoint farm since you have full access to the Server OM. While this gives you freedom as a developer a SharePoint administrator is limited in his actions and can’t set or monitor usage limits. Farm Solutions are deployed by a farm administrator to one or more Web Applications.

Sandboxed Solutions allow you to use only a subset of the Server OM. They run in a security restricted context that provides isolation and monitoring. As a developer you need to evaluate if the subset of server side code is sufficient or not. As an administrator you have more control over a solution. Sandboxed Solutions are deployed by a Site Collection administrator to a Site Collection.

Each solution package contains a manifest.xml since the solution framework needs to know what to deploy and where to deploy. If you create a lot of customizations there are a lot of files going to many different locations. So the manifest file is needed to do the mapping.

With SharePoint 2010 and the Visual Studio SharePoint Developer Tools you no longer need to take care of the manifest file. Every item you create in a project will automatically modify the manifest file.

Example 1

A solution contains all your customizations like Web Parts or Controls. The XML shows a manifest of a newly created project called ‘SharePoint2010’. It only contains a reference to an assembly which is part of the solution package and will be deployed to the Global Assembly Cache.

Example 2

Adding new customizations to a solution will automatically modify the manifest with information where to put a file if you deploy the solution to a Web Application.

By the way: The SharePoint 2010 solution schema introduces activation dependencies for solutions. If you have a solution which relies on another solution that needs to be installed first you will get an error if the other solution isn’t deployed.

This demo shows you:

  • Running Visual Studio as an administrator in order to deploy solutions to attach to the IIS worker process.
  • How to target the right platform (x64 or any CPU) when creating a project.
  • How to use the .NET Framework 3.5 as a target framework for SharePoint applications.
  • How the Visual Studio SharePoint Developer Tools abstract the creation of solutions and the manifest file.
  • How solutions are managed using Central Administration.
  • How a basic SharePoint project is structured.
  • How to change the deployment steps and how to sign the assembly.


In order to modify the functionality of SharePoint there are solutions including customizations. What’s still needed is a component which represents a single customization and which can be activated or deactivated by demand.

This component is called Feature. Please note that most customizations are part of a Feature but there are exceptions meaning that not every customization is part of a feature.

A Feature often equals a customization and can be activated or deactivated in SharePoint. You don’t need to put every customization into a feature. There are exceptions like application pages only containing an .aspx file and code behind which are usable after copied to the file system. If you want to extend an existing menu with a link to the application page you will use a feature for that.

A feature has properties like a title and includes customizations like Web Parts, Event Handler or Workflows and files like pages, images, Java Script or CSS.

As you can see in the picture there is a solution containing customizations as features: Feature.xml: The feature.xml is a definition of the feature, its properties and dependencies if needed.

Elements.xml: The feature.xml references a supporting file called elements.xml. It defines which custom files belong the feature and most important what to do with the files during deployment. Of course the feature is stored on the file system but it may be required to upload configuration files to SharePoint or to bind an Event Handler to a SharePoint list.

Therefore the element uses types to define this kind of behavior.

Custom files: In this case there is a Web Part definition which describes a custom Web Part and a CSS file. The elements.xml would tell SharePoint to upload the Web Part definition to a list where Web Part configurations are stored so it becomes available for the user. The CSS would be uploaded to a different library.

The feature has properties like a unique ID, a title and description as well a context in which a feature can be activated called scope.

The element manifest defines the location of a supporting file with additional information.

A feature can have a property which can be accessed if you add code behind to the feature.

Inside the elements file you can use CAML to add declarative statements. The module specifies a list called Web Part Gallery where all Web Part definitions are stored. The file element specifies a single Web Part Definition for a custom Web Part and a property setting the group of the file.

If the feature gets activated the file is uploaded to the Web Parts Gallery meaning that the Web Part becomes available in SharePoint and can be added to sites. Additionally the property ‘Group’ is set for the file so the contents of the Web Part Gallery can be grouped or filtered.

As you can see the element file exactly tells SharePoint what to do. Fortunately this is created automatically in Visual Studio.

Feature Scope

The feature is activated in a context. A feature can have a scope meaning that its functionality is scoped or limited to the:

  • Farm, automatically activated
  • Web Application, e.g. a custom 404 error page
  • Site Collection, e.g. Web Parts available to all sites
  • Web site, e.g. a list definition used at some sub sites

Feature Dependencies

You can also add feature dependencies. E.g. a feature for a custom list will only activate if you have activated a feature with a custom Content Type on the Site Collection level first. If the custom list relies on that Content Type the feature won’t activate until the feature with the custom Content Type has been activated. There are a few rules how features can depend on each other e.g. you can create a dependency on a higher scoped feature but not a dependency on a lower scoped feature.

As it was written above almost every feature has an elements file and custom files. As an exception you can create features only containing a feature XML and a reference to an assembly and a class. Using this combination you can execute code while activating or deactivating the feature.

Feature Receiver

This example shows a feature scoped to a Site Collection using code. A feature receiver is actually an Event Handler which handles the following events of a feature :

  • Installed, Uninstalling
  • Activated, Deactivating
  • Upgrading

As an example a Feature Receiver can be used to programmatically change the elements of the top navigation.

This demo shows you:

  • Features and their location on the file system.
  • Features inside SharePoint sites and in Central Administration.
  • How to automatically and manually create features using Visual Studio.
  • How to work with the feature node in a SharePoint project including feature designer.
  • How to change the properties of a feature.

In order to modify the functionality of SharePoint there are solutions including customizations. Features often represent single customizations and are a powerful way to extend SharePoint at any level. You can set a lot of properties for the feature itself, you can add supporting files and declarative statements telling SharePoint what to do with the supporting files. You can also add custom code to the feature. What this overview is missing are the new upgrade capabilities of features in SharePoint 2010.


Since it’s possible to create and package customizations we need a way to deploy the package across the SharePoint farm.

The terminology differs but in general it’s about adding a solution, deploying it to a Web Application and activating its features. If you use the SharePoint Management Shell for the process the terminology differs for the deployment scenario. Using PowerShell is the recommended way to add and deploy solutions. Although it’s possible to use the Server OM or Central Administration (missing the ‘add’ step) to do the same things you will mostly use PowerShell or the Visual Studio built-in deployment functionality.

In order to add solutions the solution package is placed at one of the SharePoint servers. Using the PowerShell command below adds the solution to the SharePoint solution store which is a table in the configuration database. At this point there are no changes made to the file system or content database.

PowerShell command: Add-SPSolution -LiteralPath c:\solution.wsp

Removing solutions deletes it from the solution store in the configuration database. The command has to be run on a SharePoint Server using PowerShell.

PowerShell command: Remove-SPSolution -Identity solution.wsp

Deploying solutions allows you to enable your customizations in a Web Application so they become available. At this step files are copied from the solution to folders on the file system using the manifest.xml as the mapping. Additionally changes are made to the configuration or content databases.

In detail there is a Timer Job running on every SharePoint Server which uses the SharePoint Foundation Administrative web service for the process. After the files are deployed a restart of the Internet Information Services (IIS) is done.

PowerShell command: Install-SPSolution –Identity solution.wsp -GACDeployment

Retracting a solution allows you to remove your customizations from a Web Application and the file system. During this process features and other files are removed from the SharePoint server and the configuration database. Internet Information Services (IIS) will be reset.

While the functionality is disabled and files are removed from the file system not all files will be removed from the Web Application. There are exceptions like Web Part definitions which are still stored in the Web Part Gallery.

PowerShell command: Uninstall-SPSolution -Identity solution.wsp

Upgrading a solution can be done in 2 ways where the first one is called replacement. The solution is retracted, optionally removed, added again and deployed. The process is required e.g. if a features is added or removed from a solution, the unique ID or the scope of a feature changed.

In order to update a solution the solution package has to be placed on a SharePoint server and the PowerShell command has to be run. The old solution is automatically retracted and after the process has finished the new solution is deployed. (The retraction step isn’t shown in the picture) The process won’t work if you have added a new feature to the solution or removed one.

PowerShell command: Update-SPSolution -Identity solution.wsp

This demo shows you:

  • The deployment using Visual Studio.
  • The deployment using PowerShell.
  • How a mapped folder works.
  • How files are still stored in SharePoint after retraction.

In order to modify the functionality of SharePoint we have solutions including customizations. Features often represent single customizations. Solutions can be deployed across the SharePoint farm.

SharePoint has capabilities and a company has business needs. You can use building blocks to create applications meeting these needs. Therefor you have APIs, developer tools and platforms. The difference between ASP.NET and SharePoint impacts your work.

Using the Solution Framework we can extend SharePoint in a consistent way across different servers and environments. For a developer it’s easier to add and change functionality.

Both videos gave you an overview about SharePoint development and insights how customizations are put into solutions and features and how they are deployed to SharePoint.

blog comments powered by Disqus