Team-Based Development with SharePoint 2010

  • Article

Summary:  Learn how to implement a team-environment custom development of SharePoint 2010 projects by using Visual Studio 2010 and SharePoint Designer 2010. Also learn what to consider before starting SharePoint development projects.

Applies to: Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

Provided by:  Andrew Connell, Critical Path Training, LLC (SharePoint MVP)

Contents

  • Introduction to Team-Based SharePoint 2010 Development

  • Components of a SharePoint Project

  • SharePoint Project Implementation Options

  • Development Tools Available for SharePoint Developers and Implementers

  • Configuring the Typical SharePoint Development Team Environment

  • Deployment Models for SharePoint

  • Upgrading Deployed SharePoint Projects

  • Troubleshooting Custom Deployment Components

  • Conclusion

  • Additional Resources

Introduction to Team-Based SharePoint 2010 Development

Microsoft SharePoint 2010, which includes Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010, offers a comprehensive story for collaboration, content management, business intelligence, social networking, and electronic forms. In addition to the robust built-in functionality, SharePoint 2010 is also very extensible, and provides developers with many options to create custom solutions that meet specific business needs.

SharePoint 2010 is a Microsoft ASP.NET application, and many of the team-based development techniques and approaches used in ASP.NET projects apply to SharePoint 2010 projects. However, there are also significant differences. This article discusses the differences that exist in SharePoint 2010 projects compared to ASP.NET projects, specifically in the areas around team-based development. In addition, this article addresses things to consider in developing SharePoint solutions as they are moved between environments, such as development, build, integration, test, quality assurance, staging, and ultimately into production.

Teams creating SharePoint 2010 customizations will have different approaches to developing projects, depending on the size and background of the development team, and the size and subject matter of the scope of the project. Because there are multiple factors at play in setting up and implementing a team-based development approach for SharePoint 2010 projects, this article does not attempt to describe a one-size-fits-all process. Instead, developers and development managers should use what is addressed in this article to create a process and guidelines that fit the size of their specific development team and background and the type of the project.

Improvements for Developers in SharePoint 2010

Microsoft focused a great amount of effort on the developer and tooling story in SharePoint 2010. The biggest improvement for developers is that Microsoft Visual Studio 2010 includes native, first-class development tools. With this strong new support for SharePoint 2010 development in Visual Studio 2010, developers can also easily take advantage of enterprise source control solutions such as Microsoft Visual Studio Team Foundation Server 2010. Microsoft also improved Microsoft SharePoint Designer 2010 to support the export and reuse of certain customizations.

Aside from new and improved tooling, SharePoint 2010 is no longer limited to being installed on just a server environment for local development as was the case with Windows SharePoint Services 3.0 and Office SharePoint Server 2007. Developers can now install SharePoint 2010 on a client operating system (Windows 7 x64, Windows Vista Service Pack 1 x64, and Windows Vista Service Pack 2 x64), which lowers the maintenance and entry bar for many of us.

When building custom solutions in SharePoint 2010, developers can create very elaborate solutions, known as farm solutions, which are deployed to the server by an administrator. Or, they can create sandboxed solutions that are more limited in scope and require no farm administrator involvement. Site collection administrators can deploy, activate, and deactivate sandboxed solutions. This greatly reduces the development time and deployment of custom solutions and takes into consideration some acceptable compromises.

Traditionally, most SharePoint custom solutions are deployed to the server where SharePoint is installed and configured. In SharePoint 2010, there is a new option to create custom solutions that run off the server that is running SharePoint, such as in the browser, by using Microsoft Silverlight or ECMAScript (JavaScript, JScript). This is facilitated by using the new SharePoint client object model.

SharePoint 2010 addresses other challenges that developers faced in earlier versions in the areas of upgrading SharePoint Features, enforcing dependencies between two deployment packages, and simplifying the logging and debugging of custom solutions. All of these topics, and more, are discussed in this article.

Components of a SharePoint Project

SharePoint 2010 provides developers with many different kinds of components that can be built to extend and customize the native SharePoint experience. Developers will create three kinds of things:

  • Assemblies  Many things in SharePoint require custom code. To name a few, these include code-based workflows, field types, Web Parts, event receivers, and timer jobs.

  • Declarative solutions  In addition to custom code solutions, SharePoint 2010 also has a strong dependency on declarative solutions. These types of components use XML that either serves as an instruction for SharePoint to do something (as in the case of Feature element manifests), or defines a component (as in the case of site columns or content types).

  • Resources  Resources are usually referenced by other components. These include images, external script libraries, .css files, master pages, content pages (*.aspx files), and user controls (*.ascx files).

When creating custom components in SharePoint 2010, developers rarely create just one of these types of components in isolation. For example, although a traditional Web Part is completely contained in an assembly, an XML file (*.webpart), which is declarative, is deployed and provisioned to the Web Part gallery.

SharePoint Project Implementation Options

Before embarking on a SharePoint 2010 project, it is important to understand the types of implementation options that are available to development teams. One of the most important things is to understand the advantages, disadvantages, and implications of the implementation path that is selected for a project before the project begins.

The two project implementation options are known as SharePoint customization and SharePoint development, which are described in the following sections. Development teams do not have to pick one option and stick with it, because most projects employ varying degrees of both options. Before looking at the two options, it is important to understand another concept that affects each option: the differences between customized files and uncustomized files.

Understanding Customized and Uncustomized Files in SharePoint

When a new SharePoint site is provisioned, either when it is created as the top-level site within a new site collection or as a subsite within an existing site collection, most files begin in an uncustomized state. This means that although the file exists within the virtualized file system of a SharePoint site in the content database and is seen from within SharePoint Designer 2010, the entry in the content database simply points to the file it is based on in the file system. This file is sometimes referred to as a template file or file definition. When a new file is created that is based on it within a SharePoint site—otherwise referred to as provisioning the file, the file now acts as the source to the one within the content database. The file remains in an uncustomized state as long as the source of it is not modified by using SharePoint Designer 2010 or in another way through the SharePoint API.

A file can also become customized. The most common way to customize a file is to open it in SharePoint Designer 2010, make any changes to it, and then save the file. When someone saves a file in SharePoint Designer 2010, the source of the updated file is saved to the content database. Subsequent requests for the file retrieve its source from the content database instead of from the file system. For example, when you add an instance of default.master to your SharePoint solution, a copy of the default.master template file located on the file system is deployed with the solution. But if you customize default.master, the edited version is added to the content database. Any future requests for that file are retrieved from the copy in the content database, not from the file system. Figure 1 shows this process of customization and subsequent retrieval from the content database.

Figure 1. SharePoint 2010 process for retrieving files

SharePoint 2010 process for retrieving files

You might be familiar with the older terms used in early versions of SharePoint that have since been replaced with the terms customized and uncustomized. The term uncustomized was referred to as ghosted, and customized was referred to as unghosted.

For more information, see Understanding and Creating Customized and Uncustomized Files in Windows SharePoint Services 3.0. Although this article addresses Windows SharePoint Services 3.0 and Office SharePoint Server 2007, all the concepts and characteristics also apply to SharePoint 2010.

Project Implementation Option 1: SharePoint Customization

The first project implementation option involves working exclusively with customized files. This means that files are created directly on the SharePoint site by using the SharePoint API or a tool such as SharePoint Designer 2010. This approach is usually much quicker than the alternative and is more suited to teams that may not have a depth of experience in SharePoint development.

The customization approach also provides developers with a what-you-see-is-what-you-get (WYSIWYG) experience by using the Design mode in SharePoint Designer 2010, which shows developers a preview of how the page will render.

The biggest challenge with the SharePoint customization approach is in the portability and reusability of custom solutions. After a file is customized (or if it begins as a customized file), it exists exclusively in the content database with the site's content. Therefore, a simple backup of the content database from one environment to another is not a viable option because it overwrites the content in the target environment. This makes it challenging to move between environments, such as between developer workstations, into a central build environment, into testing, into staging, and ultimately into production. You can do this process, but not without some manual work or custom scripting.

Another challenge that has the potential for greater negative impact is the fact that customizations take place directly in production without the possibility of testing before committing the changes. Before a developer gets a chance to see the effect of any changes, these changes are already committed to production because they occurred in a live environment. This means that all changes are immediately seen by all users. Further complicating this scenario, it is not always easy or possible to undo or roll back file changes.

Project Implementation Option 2: SharePoint Development

The second project implementation option involves striving to keep the files involved in the project in an uncustomized state. To keep files within a SharePoint site uncustomized, you must create them as physical files on the file system. After the files are created and added to the file system on the SharePoint front-end web servers, you have to add them to the site somehow. You do this by using SharePoint Features, specifically the Module element and the associated File element in a Feature's element manifest file. By using the Feature schema, developers can provision files into SharePoint based on file templates that are used within the Feature.

A benefit of this process is that it works well with those development teams who have a structured deployment process of moving projects from development to a central build server for integration with other components, to a test environment, to a staging environment, and ultimately into production. Because these files live on the file system, it also works well with enterprise source control solutions such as Microsoft Visual Studio Team Foundation Server 2010.

Because the files reside on the file system and are provisioned by using Features, which also reside on the file system, the files can be packaged and deployed between environments quite easily.

Project Deployment Options for SharePoint

After a developer or development team has built a custom solution for SharePoint, the next question is can it be deployed into an environment. If the solution consists of customized files that were created and customized through the browser or by using SharePoint Designer 2010, you must move these files between environments manually or through some combination of manual steps and custom scripts, depending on what was built.

If the uncustomized development approach is selected, developers have two options for deploying their solutions to the SharePoint servers in the farm. One uses farm solutions, the same type of solution packaging deployment that is available in Windows SharePoint Services 3.0 and Office SharePoint Server 2007. The other option is new to SharePoint 2010: sandboxed solutions.

Using SharePoint Farm Solutions

A farm solution is a package that contains all the files that must be deployed to the server. The package is a Microsoft CAB file with a *.wsp extension. In addition to the files included in the custom solution, the package contains a manifest.xml file that tells SharePoint what files are in the package and where to deploy them. Farm solutions can deploy assemblies and any type of SharePoint resource to the SharePoint servers in the farm. The following are the advantages and disadvantages of using farm solutions.

Advantages of Farm Solutions

  • No limitations on the kind of solution, file, or resource that a farm solution can deploy to the server.

  • Assemblies in a farm solution have access to the entire SharePoint API.

  • Custom code deployed by using a farm solution runs faster than code deployed by using a sandboxed solution because it is not subject to the resource monitoring associated with the user code service.

Disadvantages of Farm Solutions

  • Must be deployed by a farm administrator.

  • Because assemblies that are deployed by using farm solutions have access to the entire SharePoint API, assemblies will need a thorough code review.

  • Because farm solutions are not monitored, they can affect the page they are running within or even the application pool that is hosting the SharePoint site.

Using SharePoint Sandboxed Solutions

Sandboxed solutions, new in SharePoint 2010, address many of the challenges of farm solutions. A site collection administrator can add and deploy these solutions to a site collection through the browser. This capability speeds the development and deployment time as the customer, typically a site collection administrator, and developer do not have to involve administrators in the deployment process. Likely, these are the only types of solutions that will be permitted in a hosted environment such as Microsoft SharePoint Online Standard (BPOS-S), while Microsoft SharePoint Online Dedicated (BPOS-D) does support farm solutions. The resources deployed by using a sandboxed solution are also isolated from the processes that host the application pools. So if something catastrophic occurs, it affects only the item that triggered the problem, not the entire page or application pool.

This flexibility comes at a cost. Sandboxed solutions do not have access to the full SharePoint API, are limited in what they can deploy, and are subject to a more restrictive code access security (CAS) policy. For more information about CAS and SharePoint, see Administrator and Developer Guide to Code Access Security in SharePoint Server 2007. Although the article notes that it applies to Windows SharePoint Services 3.0 and Office SharePoint Server 2007, all the concepts apply to SharePoint 2010. In addition, SharePoint administrators have tools such as automatic resource monitoring, allocation, and management to ensure that the health of the servers in the farm is not adversely affected by custom code being deployed to the servers without their knowledge.

For more information about sandboxed solutions, see Sandboxed Solutions in SharePoint 2010 in the SharePoint 2010 SDK. The SharePoint Guidance by the Microsoft patterns & practices group is also a fantastic resource for learning more about sandboxed solutions. The following are the advantages and disadvantages of using sandboxed solutions.

Advantages of Sandboxed Solutions

  • Sandboxed solutions can be deployed without a farm administrator's involvement, which reduces the time from design to development, and ultimately to deployment.

  • The contents of a sandboxed solution are monitored so that if an error occurs, it does not bring down an entire web process or the page the resource is contained within; only that specific part of the page breaks gracefully.

Disadvantages of Sandboxed Solutions

  • Typically, sandboxed solutions work only within the confines of the site collections to which they are deployed.

  • Slower than resources that are deployed in a farm solution because they are subject to automatic resource monitoring and management.

  • Developers cannot build and deploy everything in a sandboxed solution that they can within a farm solution, such as workflows that are developed by using Visual Studio 2010 or timer jobs. Also, sandboxed solutions cannot elevate privileges, interact with the farm, or host web applications.

How SharePoint Project Development Differs from ASP.NET Development

Because SharePoint 2010 is an ASP.NET application, many techniques and processes employed by ASP.NET developers and development teams can be used in SharePoint 2010 projects. However, SharePoint 2010 does have some nuances that require some processes and expectations to be addressed when coming from ASP.NET projects. One such example is keeping the schema of content being stored separate from the actual content. In a traditional ASP.NET application, this means modifying the database tables with scripts. To store content, SharePoint projects can take advantage of SharePoint lists instead of database tables. The challenge with this approach is that the schema of the list and its contents are stored in the same database.

The schema of the list can be changed, but this generally requires writing custom code or scripts that are run during the upgrade process. Keep this in mind when designing a custom SharePoint project that relies heavily on a list schema. One way to mitigate this is to use external content types and external lists provided by Business Connectivity Services. An external content type describes the schema and how to connect to data that that lives in a database table. An external list leverages the external content type and surfaces the data within the external database to the user as a SharePoint list. This external list is also available through the SharePoint API. Using this approach, developers could use the same practices they use in their ASP.NET projects.

One major difference between ASP.NET development and SharePoint 2010 development is how the development tools are used. In an ASP.NET project, developers open the site in Visual Studio 2010, edit the code files directly, and then debug the code files in place. SharePoint 2010 differs from this approach in that developers cannot open a SharePoint 2010 site in Visual Studio 2010. Instead, developers create components that are deployed to SharePoint 2010 and then run in SharePoint. After the solution's components are deployed to SharePoint 2010, the Visual Studio 2010 debugger attaches to the web processes that are hosting the SharePoint 2010 site (where the custom code is running) to debug the solution.

Persisting SharePoint Project Configuration Settings

One common challenge developers have to address in SharePoint projects is where to store configuration settings. For example, some projects have to connect to a database or to a web service, or store user names and passwords. Developers have many options for storing and managing configuration information in a SharePoint project. The following list provides a few suggestions developers can use:

  • SharePoint Lists (SPList)   A list can act as a database table for storing information. This is good if many of the entries of a similar schema must be persisted. Lists are also exposed through the user interface (although they can be hidden from the navigation), which may not be suitable for some scenarios.

  • SharePoint Sites (SPWeb) or Lists (SPList) Property Bags   SharePoint sites and lists also contain a property bag that consists of name-value pairs. These are not exposed through the user interface but can be accessed and modified via custom code.

  • SharePoint Persisted Objects (SPPersistedObject)   Persisted objects enable developers to create a serializable class and attach it to specific objects, such as the farm, a web application, or a site collection. These objects are then persisted by SharePoint and can be read and written by using custom code.

  • External Database   As in every type of application, developers can use a custom database to store configuration information in a custom external database.

The guidance provided in Developing Applications for SharePoint 2010, by the Microsoft patterns & practices group, includes a discussion about addressing the persistence of configuration information. The guidance also provides a reusable library for managing configuration information.

Development Tools Available for SharePoint Developers and Implementers

Microsoft has significantly improved the tools available to developers and implementers for SharePoint 2010. The two primary tools, SharePoint Designer 2010 and Visual Studio 2010, have evolved into first class power user, site owner, and developer tools that target different audiences.

Improvements in SharePoint Designer 2010

Microsoft has made 32-bit and 64-bit versions of SharePoint Designer 2010 available as free downloads from their site for all users. SharePoint Designer 2010 is significantly upgraded from the previous version, SharePoint Designer 2007. SharePoint Designer 2010 focuses on the tasks, functionality, and features of a SharePoint site and enables developers and site owners to quickly and easily create such things as sites, declarative workflows, site columns, content types, lists, pages, and master pages.

Note

All changes to a site that are made by using SharePoint Designer 2010 occur over HTTP/HTTPS, and therefore the changes will reside in the site's content database. This means that all changes are customizations.

However, unlike the earlier version of SharePoint Designer, users can save some resources, such as workflows, as templates, export them to their local workstation, and include them in the deployment to another environment manually or by using a farm or sandboxed solution (depending on what is being exported).

Through Central Administration, SharePoint 2010 also enables farm administrators to block the use of SharePoint Designer 2010 (and specific actions it can perform) on all site collections in a specific web application. In addition, if a farm administrator has allowed its use on a web application, site collection administrators can further limit it at the site collection level through the site collection's Site Settings page.

Note

SharePoint Designer 2010 does not interact with the file system, either locally on the user's workstation or on the SharePoint servers. It interacts directly with the SharePoint site. This means that SharePoint Designer 2010 cannot interact with an enterprise source control solution.

For more information, see Using SharePoint Designer for SharePoint Development.

SharePoint Development Tools in Visual Studio 2010

Visual Studio 2010 is the primary development environment for all custom code and resource development for SharePoint 2010. Visual Studio 2010 Professional, Visual Studio 2010 Premium, and Visual Studio 2010 Ultimate versions include native, first-class development tools, wizards, designers, and tool windows for developing custom solutions for SharePoint 2010. Visual Studio 2010 includes many project templates and project item templates that developers can use to build things such as workflows, content types, list templates or list definitions, list instances, Features, event receivers, and Web Parts.

Developers can also use a new project template that can rebuild a solution by importing an existing solution package (.wsp) file. Visual Studio 2010 provides a new extensibility model named the Managed Extensibility Framework (MEF), and a SharePoint 2010 project system API. Using this framework and API, developers can extend and customize Visual Studio 2010. The following are a few popular projects that are supported by Microsoft and the community that add more capabilities for SharePoint developers by using Visual Studio 2010:

Visual Studio 2010 also enables developers to add projects and solutions to enterprise source control solutions such as Microsoft Visual Studio Team Foundation Server 2010, and to integrate their development into their team software development life cycle (SDL) and application life cycle management (ALM) processes.

Configuring the Typical SharePoint Development Team Environment

SharePoint 2010 enables developers to configure their workstations in a variety of ways to provide the most flexibility. The configuration options for a large team or small team, or even for the development staff that consists of a single person, are relatively the same for all scenarios. The following sections explain what is required to do SharePoint development, what options are available, and how to test SharePoint projects.

SharePoint Development Workstation Configuration

The project implementation option that is selected and the deployment target of the solution have an impact on how the developer's workstation is configured. For a pure customization approach, developers need to install only SharePoint Designer 2010 on their workstation because they will connect to a SharePoint site that does not reside on their workstation. For the development approach, developers must install SharePoint 2010 on their workstations.

Developers must have a local instance of SharePoint 2010 installed on their system to do SharePoint 2010 development. This is because the new SharePoint development tools in Microsoft Visual Studio 2010 can deploy, debug, and interact with only SharePoint sites that are running on the same computer as Visual Studio. Therefore, there is no native support for remote debugging of SharePoint projects.

A developer workstation is usually configured in one of two ways: by installing SharePoint on the native operating system, or by installing SharePoint within a virtual machine. Because SharePoint 2010 is a 64-bit–only application, it requires 64-bit host and client support. Another option is to boot into a virtual hard drive (*.vhd) file, provided that the host operating system on the workstation is either Windows 7 or Windows Server 2008. This is similar to the traditional dual boot technique. For more information about how to configure this setup, see Boot from VHD in Win7 on Microsoft TechNet.

The alternative to the virtual approach is to install SharePoint natively. This means either installing Windows Server 2008 directly on the workstation or by using a new capability. Starting with SharePoint 2010, SharePoint can be installed on a 64-bit client-based operating system being Windows Vista Service Pack 1 x64, Windows Vista Service Pack 2 x64, or Windows 7 x64. The installation steps differ if you are installing SharePoint 2010 on a server-based operating system or client-based operating system. For installation instructions, see Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7, and Windows Server 2008.

One very helpful capability of SharePoint 2010 is that it can download and install all the prerequisites it and configure the host machine automatically. This greatly simplifies the installation process for developers because they do not have to track down different installation files, and they know they are getting the correct matching versions.

Note

One thing that is not installed is the ADO.NET Data Services Update for .NET Framework 3.5 SP1 for Windows 7 and Windows Server 2008 R2. This is required to enable a SharePoint-provided RESTful web service for reading SharePoint lists and writing to them by using RESTful techniques.

SharePoint Development Team Configuration

SharePoint developers typically work best when following the traditional isolated development model. In this scenario, each developer in a development team should have the same configuration described in SharePoint Development Workstation Configuration. This configuration means that each workstation is essentially its own mini SharePoint farm. Each workstation can have its own local Microsoft SQL Server instance or each workstation can connect to a central shared instance. If a team decides to use a shared SQL Server instance, ensure that each developer workstation does not connect to the same farm. Instead, each workstation should have its own farm and simply use the shared SQL Server instance as a shared resource. Developers should not connect their workstations to the same farm because in that case, code that one developer deploys to one workstation would be deployed to all workstations, and this would create undesirable results for other developers who are working on different solutions.

After a component is developed on a workstation, it is checked into an enterprise source control solution, such as Microsoft Visual Studio Team Foundation Server 2010. A central build server, also known as an integration server, can then be used by a development manager to get the latest code, rebuild, and deploy the solution to do integration testing with other components. For more information about building SharePoint 2010 with Microsoft Visual Studio Team Foundation Server 2010, see How to Build SharePoint Projects with TFS Team Build.

After integration testing on the build server, the package can be moved and tested in a test or quality assurance environment. After the testing stage, the package can be deployed to the staging environment and ultimately to production.

Testing SharePoint Development Projects

It is a generally accepted good practice to implement some degree of automated testing on custom developed components. Testing takes many forms. All the testing techniques developers use in non-SharePoint projects—such as unit testing, continuous integration, stress testing, load testing, and mocking—should work in a SharePoint environment.

The Microsoft patterns & practices group has published a release for SharePoint 2010, Developing Applications for SharePoint 2010, that provides comprehensive coverage and guidance on how to test SharePoint 2010 projects, including guidance for the following areas:

  • Unit testing

  • Integration testing

  • Continuous integration testing

  • Web testing

  • Stress testing

  • Functional testing

  • Build verification testing

  • Load/scale testing

  • User acceptance testing

  • Mocking SharePoint 2010 objects

  • Testing using the Moles Framework

Deployment Models for SharePoint

As mentioned previously, there are two deployment models to choose from when creating custom SharePoint 2010 development components: farm solutions and sandboxed solutions.

If a project uses the SharePoint customization implementation approach, all the site assets and customizations reside in the SharePoint content database. Typically, this approach is used when a repeatable development process—one that involves moving through the development, integration, test, quality assurance, staging, and production processes—is not required. However, when the customization implementation method is selected and changes must move through this repeatable development process, the customized assets must be duplicated in each environment as the process progresses. Or developers will have to write custom scripts—for example, by using Windows PowerShell—to extract, replicate, and automate this process.

Deploying SharePoint Farm Solutions

Farm solutions must be added to the SharePoint farm by a farm administrator who has access to the console of the SharePoint servers. This is because solutions must first be added to the farm by using Windows PowerShell cmdlets (Add-SPSolution). After the solutions are added to the farm, they can be deployed from the Central Administration website or via another cmdlet (Install-SPSolution), as shown in the following Windows PowerShell example.

$SolutionPackageName  = "WingtipDevProject.wsp"
# add the solution to the SharePoint solution store
Add-SPSolution -LiteralPath $SolutionPackageName
# deploy the solution globally
Install-SPSolution -Identity $SolutionPackageName -GACDeployment
# OR....
# deploy a solution to a specific Web application
Install-SPSolution -Identity $SolutionPackageName -WebApplication "http://intranet.wingtip.com" -GACDeployment

After a farm solution package is deployed to the servers, its components are available for use. For example, once deployed, a custom field type is immediately available for use, but a site collection Feature is just installed and made available for activation.

Deploying Sandboxed Solutions

The deployment of sandboxed solutions is different from the deployment of farm solutions. A sandboxed solution package must be uploaded to the Solution Gallery, a special gallery that exists in the top-level site within a site collection. Only site collection administrators have rights to upload sandboxed solutions to the Solution Gallery. After the sandboxed solution is in the Solution Gallery, it must be activated before its contents (for example, a Web Part) are available for use. Activation of a sandboxed solution automatically activates any site collection-scoped Features by default. However, Feature activation can be customized by using Feature properties that scope the Feature to the site collection level.

Deployment in Content Management Solutions

Custom development projects that involve publishing sites or web content management (WCM) warrant a special mention. WCM, included in SharePoint Server 2010, contains all the capabilities and technologies that enable customers to implement a content management system (CMS) within the SharePoint platform. A CMS has a clear separation of the content within a site from the code and branding that implement the site. At times, content has a dependency on other content within the site. Developers should strive to keep content and the supporting resources, such as master pages, page layouts, branding files, and assemblies separated. Content should be developed and created only within an authoring environment. The deployment, upgrade, and management process of the custom components in a CMS-based project would follow the same process as that for a typical SharePoint collaboration site.

Frequently, developers have to test new code or components against real world content. The best option in this scenario is to take a copy of the production environment, or a portion of production when handling very large implementations, and replicate it in a development environment. Then, developers test their custom components against this local development refreshed copy of the production site.

Upgrading Deployed SharePoint Projects

After a custom SharePoint 2010 project is deployed to production, there will inevitably come a time when one or more of the components should be updated. Different components and deployment mechanisms require different upgrade processes and methods. The previously mentioned Developing Applications for SharePoint 2010 from the Microsoft patterns & practices group includes comprehensive guidance on upgrading SharePoint 2010 projects.

Troubleshooting Custom Deployment Components

At some point, developers must troubleshoot or debug the custom solutions built for SharePoint 2010. Microsoft has added capabilities to assist in troubleshooting and debugging. For example, it is now easier to write entries to the SharePoint Unified Logging Service (ULS), which includes the server event log and text files that existing on all servers. Custom solutions can write directly to the logs by using the SharePoint API from assemblies that are deployed in farm solutions. Sandboxed solutions can also write to log files through a full trust proxy object.

SharePoint 2010 also includes a series of timer jobs that when enabled, aggregate the contents of the log files, system activity, and performance metrics from all servers in the farm to a single database. Developers and administrators can query the database in searching for problems, or specific entries when troubleshooting issues that arise. In addition, all errors and log entries are tagged with a correlation token, a unique ID, which is presented to a user when an error occurs. This makes it easier to find a specific entry in the logs.

Another addition to SharePoint 2010 is the Developer Dashboard. This can be turned on for an entire farm or on a page-by-page basis. It contains details on various activities undertaken by SharePoint for the specific page request such as database queries, service calls, and demographic information on the current user, server, and page, and the duration of specific actions. Developers can even include code in their custom solutions to include in the Developer Dashboard when it appears on the page.

For more information about debugging and logging in SharePoint 2010, see Debugging and Logging Capabilities in SharePoint 2010.

Conclusion

This article introduces developers, development teams, and development managers to the concept of team-based development in Microsoft SharePoint 2010. After explaining the different kinds of components developers can create, it provides guidance around the different custom deployment implementation and deployment options. The two primary tools developers use in creating custom SharePoint solutions, SharePoint Designer 2010 and Visual Studio 2010 are discussed, including the advantages and disadvantages of each. Next, the article describes the options for configuring a developer workstation and how a development team works together. Finally the concepts of deployment upgrade and troubleshooting custom SharePoint 2010 development projects are addressed.

Additional Resources

For more information, see the following resources: