Farm Solutions

Typically, farm solutions are packaged as SharePoint solution package (WSP) files that contain assemblies, other non-compiled components, and an XML manifest file. A farm administrator uses Windows PowerShell, the STSADM command-line tool, or the SharePoint Central Administration Web site to install solution packages to the server environment. After a solution package is installed, the farm administrator can activate the solution to a specific Web application (or multiple Web applications, if you use the full-trust model).

As described in other topics in this section, you can configure your farm solutions to use a full-trust execution model or a bin/CAS execution model. When you use the full-trust approach, the solution package deploys your assembly to the global assembly cache on each Web server. When you use the bin/CAS approach, the solution package deploys your assembly to the bin folder of a specific Web application in the Internet Information Services (IIS) file structure on each Web server. In both cases, the solution package can deploy other components such as resource files, ASCX user controls, and ASPX Web pages to the SharePoint directory structure on each Web server (commonly referred to as the "SharePoint root").

This topic explains the technical details behind the execution models for farm solutions, and it identifies some of the key execution issues that you should consider when you work with farm solutions. The topic largely focuses on the full-trust execution model, because the bin/CAS model is no longer considered a recommended approach.

How Does the Full-Trust Execution Model Work?

The precise details of a how full-trust solution executes vary slightly, depending on the type of SharePoint component that you have deployed. For example, Web Part assemblies and event receivers are loaded by an IIS worker process (W3wp.exe), while timer jobs are loaded by the SharePoint timer job process (Owstimer.exe). However, the concepts remain broadly the same (although the timer process typically runs under an account with higher permission levels than the IIS worker process). In this case, this example assumes you have deployed a Web Part. A request that invokes your Web Part logic is directed to the IIS worker process that manages the Web application associated with the request. The IIS worker process loads the appropriate assembly from the global assembly cache. Because the assembly is located in the global assembly cache and as such is not subject to code access security policies, it has unrestricted access to the SharePoint object model and to any other APIs that are accessible from the worker process. The assembly is also able to access remote resources such as databases, Web services, and Windows Communication Foundation (WCF) services. The following illustration shows the various components of full-trust execution.

The full-trust execution model

How Does the Bin/CAS Execution Model Work?

When you deploy a farm solution using the bin/CAS execution model, the assembly is added to the bin folder in the IIS file structure for your SharePoint Web application. As a result, the assembly can be loaded only by the IIS worker process associated with that Web application (in contrast to the full-trust execution model, where your global assembly cache–deployed assemblies can be loaded by any process). This difference precludes the use of bin/CAS solutions to deploy various SharePoint components, such as timer jobs, event receivers, service applications, and workflows, which require your assemblies to be available to other processes.

Requests that invoke your code are directed to the IIS worker process that runs the Web application associated with the request. The IIS worker process loads the appropriate assembly from the Web application's bin folder in the IIS file system. Because the assembly is located in the bin folder, it is subject to the code access security policies defined in the configuration file for the Web application. These policies define the degree to which your assembly can use the SharePoint object model as well as other APIs, databases, and services. The following illustration shows the various components of bin/CAS execution.

The bin/CAS execution model

What Can I Do with Farm Solutions?

Full-trust farm solutions have no limitations in terms of functionality or scope. You can deploy every type of SharePoint component with a full-trust solution, and you can make your components available to site collections across the server farm.

Bin/CAS solutions are more limited. Scope is restricted to the target Web application, and functionality is constrained by the code access security policies that are applied to the Web application. Bin/CAS solutions are also unsuitable for the deployment of timer jobs, event receivers, service applications, and workflows. These components require assemblies to be deployed to the global assembly cache, as explained earlier in this topic.

What Are the Core Issues for Farm Solutions?

Each execution model creates a different set of challenges for the developer. Farm solution development creates particular issues for consideration in the areas of deployment, capabilities, stability, and security. The next sections describe each of these.

Deployment

When you create a full-trust farm solution, there are no limits to the types of resources that you can deploy. Nor are there restrictions on the locations within the server file system to which you can add these resources. However, your organization may limit or prohibit the deployment of farm solutions due to security or performance concerns. In many cases, your application may also have to undergo a formal code review before you can deploy the solution to the server environment.

Capabilities

Full-trust farm solutions execute without any code access security restrictions and run using the same process identity as the code that invokes your solution. Typically, your code will run in the IIS worker process (W3wp.exe), the SharePoint Timer process (Owstimer.exe), or a service application process, depending on your execution logic. As a result, your code executes without any restrictions—in other words, your code can do whatever the SharePoint platform itself can do. In cases where security or stability are not significant issues, or where the application undergoes a high level of functional and scale testing, a farm solution is an appropriate choice. Otherwise, consider running only the components that specifically require a farm solution deployment within a farm solution. Components that can run within the sandbox environment should be deployed in a sandboxed solution.

Stability

Farm solutions are not subject to any monitoring or resource allocation throttling. Poorly written code in a farm solution can jeopardize the performance and stability of the server farm as a whole. To prevent these issues, you should carefully review your farm solution code to identify issues that could cause memory leaks or process timeouts. For example, developers often encounter the following pitfalls that can adversely affect performance:

• The developer could fail to dispose of SPSite and SPWeb objects after use.
• The developer could iterate through items in large lists instead of executing queries on the lists.
• The developer could use for or foreach loops to aggregate data, instead of using SPSiteDataQuery or other recommended data aggregation methods.
• The developer could use recursive method calls to iterate through information in every site within a site collection.
• The developer could fail to close connections to external systems after use.
• The developer could fail to trap timeouts when connecting to external systems.
• The developer could overuse, or improperly use, session state.

This is not an exhaustive list instead, it simply illustrates that there are many different ways in which you can unnecessarily slow your SharePoint environment. To minimize risks to farm stability, you should review your solution code against all best practice guidance in the relevant functional areas.

Security

Farm solution code runs in the same process space as SharePoint itself. These processes run using privileged accounts. Both of these factors increase the scope for harm if your code is compromised or exploited. Even if you deploy your code using the bin/CAS approach and apply restrictive code access security policies, the risk of a damaging security exploit is substantially higher than you would encounter through a sandboxed solution. You should take care to review your code for security vulnerabilities before your deploy your solution.