Introduction to SharePoint 2010 Development

Article
10/20/2016

Summary: Learn how developing applications in Microsoft SharePoint 2010 is fundamentally different from working with other development platforms, such as Microsoft ASP.NET. This article discusses developer opportunities and describes the different types of templates and components that can be created in SharePoint development projects. It also provides an overview of common types of SharePoint projects that you can use to customize and extend SharePoint 2010 environments.

Provided by: Ted Pattison (SharePoint MVP), Critical Path Training | About the Author

Contents

SharePoint 2010 as a Development Platform
SharePoint Development Building Blocks
Developing SharePoint 2010 Projects
Conclusion
Additional SharePoint 2010 Resources
About the Author

SharePoint 2010 as a Development Platform

Over the past few years, Microsoft SharePoint has experienced a rapid rate of adoption in the software industry. As more and more companies and organizations begin to use SharePoint technologies, there has also been a significant increase in the number of software development projects that target SharePoint environments. The industry is currently witnessing scores of professional developers who are migrating to Microsoft SharePoint 2010 from other development platforms, such as Microsoft ASP.NET, Lotus Notes, Enterprise JavaBeans, and IBM WebSphere, just to name a few.

When experienced developers first begin working with SharePoint 2010 development, they often ask the same question: "How do I create a SharePoint application?" The answer is, "You don't," which is something they might not expect. SharePoint developers do not create applications. Microsoft SharePoint Foundation 2010 already provides the applications that developers target in their development efforts. In most cases, SharePoint Foundation also provides the starting point of a fully functioning website. The key observation is that SharePoint developers do not create applications. Instead, they extend applications and websites that are created by the underlying platform.

SharePoint Farms

Every deployment of SharePoint 2010 is based on the concept of a farm. In short, a SharePoint farm is a set of one or more server computers that work together to serve up SharePoint sites and to provide functionality to clients. For a development environment, you can set up a SharePoint 2010 farm by installing and configuring everything you need on a single server. In production scenarios, a SharePoint farm might include a dozen or more server computers.

Several different products are associated with SharePoint 2010. For example, one farm could be running SharePoint Foundation 2010, while another farm is running SharePoint Server 2010. There are also multiple versions of SharePoint Server 2010, including the Standard edition and the Enterprise edition. When you create a new SharePoint development project, you must make assumptions about the types of farms that you will target. For example, the SharePoint publishing features are included with all editions of SharePoint Server 2010, but they are not included with SharePoint Foundation. If you create a development project that builds on top of the SharePoint publishing features, you will not be able to deploy that project on SharePoint 2010 farms that are running only SharePoint Foundation.

Deployment and SharePoint Solution Packages

When you develop for SharePoint 2010, you must package and deploy your development efforts using solution packages. At the physical level, a solution package is a set of files that are created in a development effort that are compressed into a single CAB file. The file name for a solution package must have a .wsp extension. The strategy of packaging and distributing each development effort as a single self-contained solution package file is important because it leads to an easier and less error-prone approach to deploying and updating code in production farms.

Solution packages were introduced in Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0. However, these products allow for the deployment of a solution package only as a farm solution. A farm solution is deployed at the farm level. In SharePoint 2010, you can deploy a solution package as a farm solution just like you can in Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0. However, SharePoint 2010 introduces a new deployment option that lets you deploy a solution package as a sandboxed solution. When you deploy a solution package as a sandboxed solution, you reduce the scope of deployment from the level of the farm to that of a single site collection. There are also some limitations on the functionality of sandboxed solutions.

SharePoint Developer Tools in Visual Studio 2010

Microsoft Visual Studio 2010 represents a significant milestone in the evolution of SharePoint development. This is because Visual Studio 2010 includes a new set of tools known as the SharePoint development tools in Visual Studio 2010. This new integrated tool set makes developing for SharePoint 2010 much faster and easier by automating grungy tasks and hiding many of the low-level details that developers have to worry about when developing for Office SharePoint Server 2007 and Windows SharePoint Services 3.0.

For example, a Visual Studio 2010 project that you create by using the SharePoint development tools in Visual Studio 2010 is a special type of project known as a SharePoint project. Every SharePoint project is created with built-in support to generate its output as a solution package. The SharePoint development tools in Visual Studio 2010 also integrate convenient commands into the Visual Studio 2010 environment that make it easy to deploy and retract the solution package that is associated with a SharePoint project during the testing and debugging phase.

Before you begin using the SharePoint development tools in Visual Studio 2010, you must ensure that your developer workstation is configured correctly. In particular, you must build out your development workstation as a single-server farm that is running either SharePoint Foundation or SharePoint Server 2010. A key point is that the SharePoint development tools in Visual Studio 2010 do not work correctly on a workstation that does not have a version of SharePoint 2010 installed. That's because the SharePoint development tools in Visual Studio 2010 were designed to run on a computer that is acting as a front-end web server within a SharePoint 2010 farm. Moreover, some of the useful commands provided by the tools, such as the deploy command, only work if the development environment is a single-server farm.

SharePoint Development Building Blocks

Although you can create many different types of components within a SharePoint solution, the most common type is a Feature. A SharePoint Feature provides a mechanism for adding elements to a target website or site collection through a process known as Feature activation. The types of elements that you can add to a site include menu commands, link commands, page templates, page instances, list definitions, list instances, event handlers, and workflows.

Every Feature has an activation scope that defines the context in which the Feature can be activated and deactivated. For example, a Feature can have an activation scope setting of Web, which means that it can be activated and deactivated within the context of the a website. If you create a Feature that has an activation scope of Site, your Feature definition is then activated and deactivated within the scope of a site collection. The two other possible activation scopes for a Feature definition are WebApplication scope and Farm scope.

When you define a custom Feature, you have the option of adding declarative elements and a Feature receiver. Declarative elements make it possible to add elements to a site during Feature activation. A Feature receiver is a class that contains event handlers with custom code, which are automatically executed as Features are activated and deactivated.

Using Declarative Elements to Add Elements to a SharePoint Site

Declarative elements are created by adding XML element definitions into special files known as element manifests. The SharePoint development tools in Visual Studio 2010 do a great job at creating element manifests for you within a SharePoint project and automatically associating them with Features behind the scenes. The SharePoint development tools in Visual Studio 2010 also provide several SharePoint project item templates that create the XML definitions for declarative element types, such as Module, ListInstance, ContentType, and ListTemplate. Some of the other declarative element types, such as CustomAction, Field, and FeatureSiteTemplateAssociation, are not directly supported by the SharePoint development tools in Visual Studio 2010. However, this is not a big problem because you can create a project item based on the Empty Element SharePoint project item type and then add the XML definition by hand. Table 1 lists the most frequently used declarative element types and indicates which element types are directly supported by SharePoint project item types.

Table 1. Most frequently used SharePoint 2010 declarative element types

Element Type	Description	Tool Support
PropertyBag	Used to add name-value properties to Features.	No
ListInstance	Used to create a list instance.	Yes
CustomActionGroup	Used to create a new section for links.	No
CustomAction	Used to create a new link or menu command.	No
HideCustomAction	Used to hide a built-in or custom link or menu command.	No
Module	Used to provision a file from a template file.	Yes
Field	Used to create a site column.	No
ContentType	Used to create a content type.	Yes
ContentTypeBinding	Used to add a content type to a list.	No
ListTemplate	Used to create a custom list type.	Yes
Control	Used to create a delegate control.	No
Workflow	Used to create a workflow template.	Yes
WorkflowActions	Used to create declarative workflows.	No
WorkflowAssociation	Used to associate a workflow template with a list.	Yes
FeatureSiteTemplateAssociation	Used to staple a Feature to a site definition.	No

Template Files and the SharePoint Root Directory

When you are developing a SharePoint project that will be deployed as a farm solution, you have more flexibility than when you develop SharePoint projects that must support deployment as sandboxed solutions. In particular, you can deploy various types of template files into a special directory on the web server that is known as the SharePoint root directory, which is located at the following path: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14.

The SharePoint development tools in Visual Studio 2010 provide a few SharePoint project item templates, such as Application Page and User Control, which handle the details of deploying files into the appropriate location within the SharePoint root directory. The SharePoint development tools in Visual Studio 2010 also let you create mapped folders, which make it possible to deploy any type of template file into any location inside the SharePoint root directory. The following table shows popular deployment locations within the SharePoint root directory along with the types of templates files that are deployed there.

Table 2. Deployment locations in the SharePoint root directory

Path relative to SharePoint root	Template file types
/ISAPI	Web services (.svc, .ashx, .asmx)
/Resources	Resource files (.resx)
/TEMPLATE/ADMIN	Application pages used exclusively in Central Administration
/TEMPLATE/CONTROLTEMPLATES	ASP.NET user controls (.ascx)
/TEMPLATE/FEATURES	Feature definition files (.xml)
/TEMPLATE/IMAGES	Images (.gif, .jpg and .png)
/TEMPLATE/LAYOUTS	Application pages (.aspx)
/TEMPLATE/LAYOUTS/1033/STYLES	Cascading style sheets (CSS) files (.css)
/TEMPLATE/LAYOUTS/ClientBin	Microsoft Silverlight components (.xap)
/TEMPLATE/SiteTemplates	Site definition files (onet.xml)
/TEMPLATE/XML	Custom field type definition files (fdltype*.xml)

SharePoint 2010 Site Templates

Developing for SharePoint 2010 differs from ASP.NET development because your starting point is usually a full-functioning website. For example, in one SharePoint project, you might want to start with a site that is created from the minimal site template known as a Blank Site. This approach gives you the most generic starting point as you add pages, lists, and document libraries to build out a custom business solution.

When building a collaboration solution, you might consider starting with a Team Site because it is automatically created with lists and document libraries used in common collaboration scenarios. If you are creating a public-facing website, you should consider starting with a Publishing Portal because it provides automatic support for branding and browser-based content authoring in addition to a structured publishing scheme with a built-in approval process.

What is important to understand is that anyone who intends to design and develop SharePoint solutions should learn about the site templates that are provided by SharePoint Foundation and SharePoint Server 2010. When you begin developing a SharePoint project that adds elements and functionality to a SharePoint site, you should document your assumptions about what site templates your project will support. Table 3 contains the most frequently used SharePoint 2010 site templates along with the associated version of SharePoint 2010.

Table 3. Frequently used SharePoint 2010 site templates

Site Templates	Version
Team Site	SharePoint Foundation 2010
Blank Site	SharePoint Foundation 2010
Document Workspace	SharePoint Foundation 2010
Meeting Workspace	SharePoint Foundation 2010
Blog	SharePoint Foundation 2010
Group Work Site	SharePoint Foundation 2010
Publishing Portal	SharePoint Server 2010 Enterprise
Personalization Site (My Site)	SharePoint Server 2010 Standard
My Site Host	SharePoint Server 2010 Standard (not available until it is set up in Central Administration)
Enterprise Wiki	SharePoint Server 2010 Enterprise
Document Center	SharePoint Server 2010 Standard
Records Center	SharePoint Server 2010 Standard
Basic Search Center	SharePoint Server 2010 Standard
Enterprise Search Center	SharePoint Server 2010 Standard
Business Intelligence Center	SharePoint Server 2010 Enterprise

Developing SharePoint 2010 Projects

Typically, the objective of developing in SharePoint is to customize or extend sites in a SharePoint farm. You should create these types of projects as SharePoint projects by using the SharePoint development tools in Visual Studio 2010. However, you could also develop a desktop application that will access a SharePoint farm over the network. New development projects that use the SharePoint development platform generally fall into one of the following categories:

General business solutions
Client-side applications
Site-level administrative applications
Farm-level administrative applications
Specialized components and services

General Business Solutions in SharePoint

The majority of new SharePoint projects are designed to directly benefit SharePoint users and make their jobs easier. These types of projects are considered general business solutions. Such projects usually provide site elements and functionality that is enabled by Features that activate at the level of the website or the site collection. The following are common site elements that are created by general business solutions:

List instances, event handlers, and workflows
List definitions, content types, site columns, and custom field types
Site pages, application pages, and navigation elements
Web Parts and user controls
Branding elements, including master pages, CSS files, and images
Client-side code written using ECMAScript (JavaScript, JScript) or Silverlight applications

Client-Side Applications in SharePoint

SharePoint 2010 introduces a new client object model and a new REST-based web service, both of which make it possible to access and update SharePoint sites over the network. These two remote APIs provide an opportunity for developers to access SharePoint sites from desktop applications that are running over the network. They also make it possible to access SharePoint sites from server-side applications that are running on servers that are not part of a SharePoint farm.

The client object model has been designed for Microsoft .NET Framework applications that are running .NET Framework 3.5 SP1 or later. The REST-based web service provides access to a wider variety of client applications, including browsers that are running on Windows and non-Windows operating systems. The REST-based web service provides wider reach because it enables you to access SharePoint sites from any application that can parse together URLs and issue HTTP GET requests.

Site-Level Administrative Applications in SharePoint

Although general business solutions target ordinary business users, it is also common to develop SharePoint solutions that provide functionality to users who are in the role of website owners and site collection administrators. The type of functionality provided in these types of SharePoint solutions include the automation of archiving older content, backing up recent content, and refreshing local lookup lists by calling web services over the network.

A common approach when creating site-level administrative applications is to provide the user interface components using applications pages that are served out of the _layouts directory. The website owners are then provided with custom links on the Site Settings page that enable them to navigate to these application pages.

Farm-Level Administrative Applications in SharePoint

In a less common scenario, a SharePoint developer may be required to develop a SharePoint solution that adds custom pages to extend the farm-level administrative functionality that is available in the Central Administration application of SharePoint 2010. These types of solutions are designed to provide farm administrators with custom pages that provide extended management functionality for site collections, web applications, and the farm itself. Examples of functionality that is included in farm-level administrative applications include monitoring and managing access control lists (ACLs) within site collections, providing custom back up schemes, and viewing and registering specialized custom components within the current farm, such as sandboxed solution validators and trusted proxy classes.

The recommended approach for creating farm-level administrative applications is to provide the user interface using administrative pages that are served out of the _admin directory. The _admin directory differs from the _layouts directory because it can be accessed only through the web application for Central Administration and cannot be accessed through any web application in the farm. The farm administrators are then provided with custom links within standard pages of the Central Administration application that allow them to navigate to these custom administration pages.

Using the SharePoint Development Platform to Create Specialized Components and Services

In addition to the types of SharePoint solutions that are described earlier, the SharePoint development platform provides several other developer opportunities to create specialized components and services, which are included in the following list.

Timer jobs
Custom Windows PowerShell snap-ins
Custom navigation providers
Custom claim providers
.NET assembly connectors
Sandboxed solution validators
Trusted proxies for sandboxed solutions
Excel Services user-defined functions
Custom web services
Service applications

Note

The SharePoint development tools in Visual Studio 2010 do not provide SharePoint project templates or SharePoint project item templates to help you create these types of SharePoint components or services. Therefore, you must learn how to add classes and other types of source files to your projects to implement them. However, we still recommend that you use the SharePoint development tools in Visual Studio 2010 by creating SharePoint projects when developing these specialized SharePoint components and services. The value of using SharePoint projects is that they automate building the solution package, which is required to deploy these components and services in a production environment.

SharePoint Timer Jobs

SharePoint Foundation provides a scheduling engine that runs administrative components known as timer jobs. SharePoint Foundation and SharePoint Server 2010 include many built-in timer job definitions for running ongoing administrative tasks, such as monitoring the health of the farm and crawling searchable content to build indexes. With SharePoint Foundation, you can create a custom timer job definition that can be scheduled and managed directly from inside Central Administration. Timer jobs are also the mechanism with which SharePoint runs code on multiple servers, such as code that edits a configuration file on all front-end web servers.

Custom Windows PowerShell Snap-ins

SharePoint Foundation and SharePoint Server 2010 farms provide a built-in library of Windows PowerShell cmdlets that enable farm administrators to automate administrative tasks through Windows PowerShell scripts. You can create a custom Windows PowerShell snap-in that contains custom cmdlets that can also be called from Windows PowerShell scripts. The advantage of creating a custom Windows PowerShell snap-in is that logic for administering a SharePoint farm can be moved out of Windows PowerShell scripts into a compiled component written in C# or Visual Basic, which programs against the server-side object model.

ASP.NET provides a framework for writing navigation providers that is used in SharePoint 2010 to supply navigation nodes for common navigation components, such as the top navigation bar and the Quick Launch. A developer can create a custom navigation provider to extend the standard navigation scheme that is provided by SharePoint Foundation and SharePoint Server 2010. For example, all the navigation that is included with SharePoint 2010 works only within the scope of a site collection. However, you can create a custom navigation provider to provide users with a navigation scheme that works across site collection boundaries.

Custom Claim Providers

SharePoint 2010 introduces a new infrastructure to support claims-based security. A developer can create a custom claim provider that looks up facts for a specific user and then adds them as claims into the user's security token. SharePoint Foundation also enables site administrators and list owners to configure access to resources such as sites, lists, and items by configuring access control in terms of custom claims added by a custom claim provider.

.NET Assembly Connectors

SharePoint 2010 includes an infrastructure named Microsoft Business Connectivity Services (BCS), which enables SharePoint sites to consume and update data from back-end systems such as database servers and web services. BCS can integrate back-end systems that are available through ADO.NET or standard web service calls without any need for custom development. However, some back-end systems are not available through ADO.NET or standard web service calls. You can create a .NET assembly connector to provide BCS integration with these types of back-end systems. Furthermore, developing .NET assembly connectors lets you add custom logic to BCS operations that read and update data from back-end systems.

SharePoint Sandboxed Solution Validators

SharePoint Foundation provides a new infrastructure for sandboxed solutions that allows for the deployment of solution packages within the scope of a site collection. A primary advantage of deploying solution packages as sandboxed solutions is that it requires no changes to the web server computers and therefore lowers the risk of deploying custom code in a production environment.

To restrict the types of sandboxed solutions that can be activated within a SharePoint farm, you can create a sandboxed solution validator that must be installed and registered in a farm. After it is registered, a sandboxed solution validator is called every time a user tries to activate a sandboxed solution within the scope of a site collection. A sandboxed solution validator can inspect the contents of a sandboxed solution and cancel its activation if the sandboxed solution does not meet the custom criteria defined by the sandboxed solution validator.

For example, a company might decide that users can activate only sandboxed solutions that are developed in house by its own development staff. To enforce this restriction, the company could develop a sandboxed solution validator that prohibits the activation of any sandboxed solution that contains an assembly DLL that has not been signed using the company unique public/private key pair.

Trusted Proxies for SharePoint Sandboxed Solutions

Code that runs inside a sandboxed solution is constrained from what it can do. For example, code that runs inside a sandboxed solution is prohibited from using many parts of the server-side object model. Furthermore, code that runs inside a sandboxed solution is prohibited from accessing any data on the local hard disk drive of the host server and also from calling over the network to database servers and web services. There are some techniques that allow code in sandboxed solutions to avoid these restrictions. One technique is to use the SharePoint client object model to access parts of the object model that are in the server-side code of the sandboxed solution.

Another technique is to develop a trusted proxy and then call to this trusted proxy from code in a sandboxed solution. A trusted proxy is a class that is deployed within a farm solution and registered within the current farm. The central idea is that code inside a sandbox solution can overcome the constraints of the sandbox by making a call to a trusted proxy. The trusted proxy runs with full trust and can make calls over the network and access any part of the server-side object model on behalf of a sandboxed solution.

Excel Services User-Defined Functions

Excel Services is a SharePoint 2010 service application that is included with Microsoft SharePoint Server 2010 with Enterprise Client Access License. This service application lets users publish Microsoft Excel worksheets to SharePoint document libraries, which can be loaded in a server-side process to perform calculations and to render the worksheet as a webpage. A developer can create a class with methods that are used to perform custom calculations inside Excel worksheets as they are processed in server-side scenarios. These types of methods are known as user-defined functions. Developing Excel Services user-defined functions is typically required when a worksheet requires calculations that are difficult or impossible to achieve in Excel Services natively using Excel formulas, such parsing together strings, or performing a look up by calling a web service over the network.

Custom Web Services

SharePoint 2010 introduces new support that makes it possible to develop and deploy a Windows Communication Foundation (WCF) web service using an .svc file that can be accessed by remote clients through a site-relative path. The advantage of providing access through a site-relative path is that code behind the web service can access the current website and site collection using the server-side object model. You can develop these types of web services as either SOAP-based web services or REST-based web services to enable SharePoint site access over the network to various client applications.

SharePoint Service Application Infrastructure

SharePoint Foundation introduces a service application infrastructure that is designed to promote the efficient sharing of resources across all sites on a farm-wide basis. It also provides a foundation for sharing resources across farm boundaries. Many of the features and services that are included with SharePoint Server 2010 are implemented as service applications, including BCS, SharePoint Search Service, Manage Metadata Service, Excel Services, and PerformancePoint Services in Microsoft SharePoint Server 2010. However, the service application architecture was also designed to be extensible. This means that any knowledgeable and motivated developer can develop a custom service application that can be deployed inside any SharePoint 2010 farm.

A key benefit to the service application architecture is that you can treat a service application as a configurable component. After installing and provisioning a service application, you can configure and reconfigure it to support several different deployment scenarios. In simple farms, you can configure an instance of the service application to run on the front-end web server. In more complex farms, you can configure a service application to run on a separate application server or in a farm of application servers.

Developing a service application is a significant undertaking that requires a much greater investment when compared to developing the other types of components and services mentioned in this article. For example, a service application must be written to query the configuration database about its current deployment configuration, and it must adjust its behavior accordingly. When a service application runs over the network on a dedicated application server, it relies on a proxy component on the front-end web server that must also be implemented by the developer who builds the service application.

The service application proxy component must be deployed along with the service application, which makes services applications harder to implement. However, it is the service application proxy architecture that provides value by abstracting away the code that is required to discover where a service application instance lives on the network. The service application proxy component also provides value by encapsulating all the WCF code that is used to prepare and execute web service calls from the web server to the target application server that is running the service application.

Conclusion

This article provides a high-level introduction to the SharePoint 2010 development platform. It is important for new SharePoint developers to understand that SharePoint development projects must be packaged and distributed using solution packages. Solution packages can be deployed as either farm solutions or as sandboxed solutions. Farm solutions are deployed at the farm-level and require you to add files to web server computers. Sandboxed solutions are deployed at site collection scope and do not require any changes to web server computers.

The SharePoint development tools in Visual Studio 2010 provide project templates for creating SharePoint projects. SharePoint projects present a great step forward for SharePoint developers because they automate the process of building and testing solution packages with a local SharePoint farm. As a beginning SharePoint developer, you should start by creating general business solutions. However, the SharePoint development platform presents quite a few other opportunities for advanced SharePoint developers to create more specialized types of components and services.

Additional SharePoint 2010 Resources

For more information about SharePoint 2010 development, see the following resources:

About the Author

MVP Contributor Ted Pattison is an author, instructor, and co-founder of Critical Path Training, a company dedicated to education on SharePoint technologies. As a Microsoft SharePoint Most Valuable Professional (MVP), Ted frequently works with the Microsoft Developer Platform Evangelism group to research and author SharePoint training material for developers early in the product life cycle while in its alpha and beta stages. Ted is also co-author of Inside Microsoft SharePoint 2010.