Microsoft SharePoint 2010 Developer's Compendium: The Best of Packt for Extending SharePoint: Build an engaging SharePoint site with Visual Studio, Silverlight, PowerShell and Windows 7 Phone with this book and e-book

Creating farm solutions has been the traditional way to create solutions in SharePoint going back all the way to the earliest versions. The Server OM provides access to the system configuration and data allowing developers the ability to create solutions or automate configuration changes.

When deployed, the solution's objects are either loaded into the server's Global Assembly Cache (GAC) or into the 'bin' directory of the Web application(s). This allows farm solutions run in the same memory as SharePoint, which means the developer can have full access to the server, farm configuration, and content. These solutions do not have the overhead of the sandbox solution's process overhead and it also allows the developer to access additional caching features available inside of SharePoint to optimize the solution's performance. This does add risk though since poorly written or tested solutions can impact overall system performance or potentially crash the system.

Farm solutions can only be deployed by a Farm Administrator, and in many cases the Governance policy may also dictate a formal review or change management process to be followed before the Farm Administrator is allowed to deploy the solution.

Farm solutions are scoped for activation at a set level: Farm, Web Application, Site Collection, or Web allowing the developer to set it based on how and where the solution will be used. Take a look at the following figure for an illustration. A generally best practice is to scope a solution as narrowly as possible to provide more control on where it is activated. It is also important to note that solutions scoped for Site or Web can be activated by their respective owners based on site permissions.

Good candidates for farm solutions include:

Sandboxed solutions were introduced with SharePoint 2010 and provide an interesting shift for custom solutions offering a path for user created and maintained server solutions. Unlike the farm solutions previously discussed, these are partially trusted solutions and there are some limitations. Where the farm solutions run in the same memory space as the main SharePoint services and application pools, Sandboxed solutions run in an isolated memory pool with resource quotas that can be managed by administrators. This means that poorly written or tested solutions cannot slow down or crash your main server processes. If a solution is having trouble running it will be automatically disabled. In addition, the resource throttling and quotas can limit the amount of resources each solution can consume within the site collection. This safe mode approach can speed up development cycle, but should not remove the need to properly test your solutions.

This separation does come at a cost though and there is some process overhead involved with communicating across the different worker processes. In cases where the solution will be actively used by a large number of people, it may be more difficult to meet any scalability requirements.

Unlike farm solutions, developers or site administrators do not need administrative access to the physical servers or to the farm's Central Administration to deploy their solutions; they only need access to upload the solution to the Solution Gallery for a specific site collection. This provides custom solution capabilities to organizations that have very strict change control policies or are prevented from deploying custom solutions as in cloud based environments.

Since the solutions are only partially trusted and uploaded to a specific site collection there are limitations. Sandboxed solutions cannot access resources outside of the farm, access a database directly, call unmanaged code, access resources in a different site collection, or write data to the local server.

For any solution that fits cleanly into a single site collection, and does not need to reach out to resources outside of that boundary, sandbox solutions offer additional flexibility. It is also important to note that a sandbox solution can also be deployed as a farm solution giving administrators the option of deploying it either way.

Good candidates for sandbox solutions include:

The Client Object Model (Client OM) is an application programming interface that supports extensive, but not full interaction with the SharePoint configuration and data. It was added with the SharePoint 2010 release to provide an easy way to interact with SharePoint configuration and data without the need for code deployed to the server. It puts a simple wrapper around the previously discussed web services simplifying the interaction and removing the need to create and parse the XML needed to interact with the Web services. The client-side code can be called from Silverlight, ECMAScript, or via your .Net code.

The Client OM can be used to include the Ajax enabled features allowing content and data refreshes or loads without the need for a page post back which reloads or redirects the page.

The Client OM is limited in that it cannot connect or perform calls outside of the site context that it is called from. This means that it cannot be used for cross-site calls or aggregating content from multiple web applications or site collections.

There are also some functions available in the Server OM that are not supported in the Web services and therefore not supported in the Client OM due to security boundaries.

Frequently Used Objects and Collections include:

Good candidates for Client OM solutions include:

The jQuery library (http://jquery.com/) can be leveraged to support client-side development and Ajax enabled functions. This JavaScript based library is completely cross-browser compliant and offers a rich set of selectors and advanced support for animations that can be used to provide a much richer interface than static HTML. This library is completely platform independent, and there is nothing SharePoint specific about this library. Since there are a number of Ajax methods that make it easy to consume web services, you can use the library to interact with SharePoint through its web services.

In its base format, you would need advanced knowledge of all of SharePoint's web services. To help simplify the development effort the SPServices library (http://spservices.codeplex.com/) was created to provide a wrapper around SharePoint's web services. This library was created in the Sumer of 2009 originally for the SharePoint 2007 version, but it is also fully functional with SharePoint 2010. While it conceptually offers the same functionality as the Client OM, it could be used for solutions that need to be backward compatible with 2007 or in cases where there is a SPServices method not supported in the current Client OM.

Good candidates for jQuery Solutions include:

There are a number of ways to deploy and manage client-side code inside of SharePoint. You can add it directly to your SharePoint page using a tool like SharePoint Designer, or you can add it to a container such as the Content Editor Web Part that is included with each of the SharePoint versions. In cases where you use the Content Editor Web Part, you also have the option of linking to your content or script stored in any network accessible location.

It is important to consider how changes and versions will be managed. If you are adding code and functionality to pages, you should have versioning configured for the library the pages are in, as well as any libraries used to store your scripts. This will allow you to compare versions or to recover a prior version if things go wrong.

Many environments have very strict change management or deployment guidelines for any code that is deployed to the server by administrators. One of the big advantages to the client-side development approach is that system users with appropriate access can deploy their customizations themselves without the involvement of the administrators or change control group. This typically means that customizations can be created and deployed very quickly without all of the formality needed for the more advanced customizations. While there is some risk that a defective customization will cause an error or unexpected results, the impact is typically localized to the page the customization is used on or the content it interacts with.

Visual Studio 2010 provides a robust environment for developing solutions for SharePoint 2010. Unlike previous versions, there is native support for most of the base project templates. It also natively supports the packaging and deployment process, producing the full feature and package objects and also supports automated deployment and retraction to/from the local SharePoint server to support development efforts.

In addition to the default templates provided by Microsoft, there is an additional community driven project that can add additional or customized project templates under the Community Kit for SharePoint Development (CKS:Dev) project available on CodePlex (http://cksdev.codeplex.com/).

In addition to any server-side development, Visual Studio can also provide a rich development experience for Client-side development of scripts and xsl, though it cannot be used to edit a SharePoint page directly or publish scripts to SharePoint outside of a SharePoint WSP package.

SharePoint Designer 2010 is a free tool targeted to Site Administrators and Information Workers. It excels as a tool that can be used for site level administration and customization. Since it connects to and interacts directly with a specified site, customizations can be deployed directly by the user, without administrator assistance. This makes SharePoint Designer an incredibly important tool in either cloud environments or environments with a strict server change control policy.

Through SharePoint Designer, you can create or customize the following:

InfoPath Designer 2010 is a tool that is included with the Office 2010 Professional Plus suite. It can be used to create electronic forms that can be submitted to a SharePoint library. The forms can configured to either open in the local InfoPath Filler client or with SharePoint Server Enterprise you have the option of deploying the forms as Web Enabled forms to Forms Services. InfoPath Designer can also be used to customize the default SharePoint list and library forms for New Item, Display Item, or Edit Item pages allowing much more robust forms far easier than creating custom Application Pages in Visual Studio.

The InfoPath Designer tool is targeted to Developers, Information Workers, and Power Users able to generate office forms and templates. It provides an easy to use graphical interface for defining form fields and easy to use property windows to configure business rules and back end data connections. It has the ability to easily connect to data sources including SharePoint lists, SQL databases, and web services including SharePoint's own web services.

When publishing the forms, you have the ability to publish it as a Content Type along with the ability to specify the form fields you would like to include as Site Columns or Library Columns. This allows you to map form fields and data to metadata available within the library. In many cases InfoPath forms are developed in conjunction with custom workflows to automate the form submission and processing previously handled by paper based processes.

For advanced cases, there is also support for including managed code inside of the InfoPath forms. While including this code complicates the overall development and deployment process, it does offer flexibility to organizations that do not have developers available to create custom Application Pages in Visual Studio. It is important to note that including managed code is not supported in Office 365 or on many cloud based environments.

There are a number of environment variables to consider that have an immediate impact on your development options.

When making a choice on the development path, it is also important to consider how or where the solution will be used. The approach may be completely different when developing a reusable solution expected to be deployed on sites throughout multiple farms, when compared to the approach for a simple solution intended to be used on only one site collection.

For the reusable solution it will be critical that updates be deployed centrally with a solution package update built within Visual Studio, but for a single use customization it may be acceptable to manually apply it where it is needed using either browser customizations, through SharePoint Designer, or with InfoPath Designer in the case of forms development.

Another example is when working on customizations to MasterPages and CSS. While this can effectively be applied to a single site collection using SharePoint Designer, it would be extremely difficult to try and maintain it manually across 1,000 site collections throughout the organization. Using Visual Studio to package and deploy the solutions will not only make the solution more maintainable, but it also gives the developer the option of including additional code that can automate additional tasks through the use of Feature Receivers and Event Receivers. Within the context of the existing example, this can include automatically setting the MasterPage when the feature is activated as well as when any new sites are provisioned.

When you are architecting or designing business solutions it is important to consider the overall scalability requirements. Consider how many users will be using the system, and what the overall performance requirements are. Designing a feature to support ten concurrent users is much different than designing a feature for five hundred concurrent users. Also, in cases of content roll-up as the number of data sources or sites increase the performance of the feature will change substantially. In some cases even commercially available roll-up features fail completely when trying to aggregate content from more than one hundred sites.

Strongly typed server-side code, running in a capable environment, will always perform better than weakly typed client-side code. In addition to actual code execution, another downsides of client-side development is that since everything is running on the client, all of the content needs to be downloaded to the client. That means there is potentially extra content being transferred, but not displayed. In addition, client-side development does not have the ability to cache data the way server-side development does.

For simple solutions or in small environments, the scalability of the solution may not be a real concern and far less important than the value provided by the easy deployment options. For more complex or heavily used solutions, the scalability of server-side development should be given serious consideration.

Application lifecycle management (ALM) is a software development process that supports the combined management of all application requirements, source, build, and testing processes. For organizations with a focus on ALM, there may be a requirement to include all formal projects and development in the ALM tool or environment such as Team Foundation Server (TFS). Development tools like Visual Studio provide full integration with standard ALM tools including TFS which means that solutions created in Visual Studio, using the Server OM will work transparently with ALM processes.

For client-side development or anything done in SharePoint Designer there is currently no support for ALM so things are not so easy. To support ALM with the other SharePoint development tools the developer will need to manually keep source files synchronized through a manual copy and paste process. This can make managing larger, more complex project using these tools and technologies a lot more tedious. In cases where you have a lot of code or a mixture of client and server code you can also consider deploying the client-side scripts to the server as part of a solution package, but in doing so you lose the flexibility and convenience of end user deployed customizations.