• A portal server with delegated administration. SharePoint enables information workers (IW) who have no knowledge of website design or website administration to create, almost instantly, attractive and functioning websites. This relieves information technology (IT) departments from the burden of creating and administering the sites, and it empowers the IWs to create their own sites for teams, blogs, wikis, and other purposes.
  
  
• A groupware application kit. SharePoint provides a platform on which IWs can create collaboration solutions that include document libraries and workspaces, workflows, wikis, blogs, and team-oriented lists, such as Events, Announcements, and Tasks. Microsoft SharePoint Workspace (formerly Microsoft Office Groove 2007) provides an offline experience for these collaboration solutions.
  
  
• A workflow host. Business processes can be systematized and modeled with workflows that are triggered by associated events; for example, the addition of a document to a document library.
  
  
• A content management application. SharePoint Server Enterprise Content Management (ECM) features include document management, records management, and web content management.
  
  
• A Business Intelligence (BI) application kit. The Microsoft Business Connectivity Services (BCS) features of SharePoint enable data from non-SharePoint sources, such as a SAP installation or Oracle database, to be accessed (read/write) just as if it were an ordinary SharePoint list.
  
  
• The operating system of an intranet. SharePoint can provide for an intranet many of the functions that an operating system provides for a computer, including storing and copying files, hosting services, starting applications, and securing data. (This is not to imply that SharePoint can only be used on an intranet. SharePoint can also host extranet and Internet-facing solutions.)
  
  
• A host for services. SharePoint deployments make data available through a client object model, the REST-based Windows Communication Foundation (WCF) Data Services (formerly ADO.NET Data Services), and many out-of-the-box ASMX web services. In addition, the SharePoint Service Application Framework provides a platform that enables developers to build scalable middle-tier services that can provide data or processing resources to other SharePoint features.
  
  
• A data store. SharePoint stores data as multicolumn lists in a Microsoft SQL Server database. You can query the data by using LINQ and also using Collaborative Application Markup Language (CAML). The data can be mirrored, backed up, restored, and, depending on the edition of SQL Server being used, you may be able to take snapshots of the data store.
  
  
• A data and processing layer for multiple user interfaces (UIs). Besides its native UI of webpages (including special versions for mobile devices), which can contain ECMAScript (JavaScript, JScript), SharePoint also supports access from Microsoft Silverlight applications and the Microsoft SharePoint Workspace client application. With the SharePoint client object model, you can access SharePoint using Windows Presentation Foundation (WPF), Windows Forms, or any other managed code application.
  
  

• Active pages (aspx files): SharePoint pages are ASP.NET pages. SharePoint controls are referenced in the page markup with a registered "SharePoint" prefix. (For more information about the ASP.NET page parsing and compiling system, see Understanding ASP.NET Dynamic Compilation. Note that the standard page parser of ASP.NET compiles a page the first time it is requested unless the page is explicitly set not to be compiled. However, SharePoint pages that have been customized by a SharePoint website owner are stored in the SharePoint content database and are not compiled when they are accessed. SharePoint uses a custom virtual path provider, an internal class named SPVirtualPathProvider that is derived from VirtualPathProvider, to locate a requested page from either the file system or the content database and load it.
  
  
• The master page/content page distinction: A SharePoint page is a merger of a master page and a content page. For more information, see ASP.NET Master Pages and Master Pages. (For some SharePoint Server pages, a third foundational page is involved in the merger, a page layout.)
  
  
• Web Parts: Web Parts actually originated in an early version of SharePoint. The idea was adopted by ASP.NET. In most SharePoint Web Part development situations, we recommend that you use the ASP.NET version, but in some situations the original SharePoint incarnation is a better choice. The SharePoint UI for mobile devices also uses the ASP.NET concept of registered Web Part adapters. For more information about Web Parts in SharePoint, see Building Block: Web Parts and Building Block: Mobile Pages, Controls, and Adapters.
  
  
• User controls (.ascx files): Many SharePoint web controls and Web Parts are built with ASP.NET user controls.
  
  
• Web services (.asmx files): Some, but not all, SharePoint web services are implemented as ASP.NET ASMX services. For more information about ASP.NET web services in SharePoint, see ASP.NET Web Services.
  
  
• Virtual directories: SharePoint maps several virtual directories in each IIS website to physical folders in the SharePoint root, which is the folder %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\. When you as a developer need to provision SharePoint web applications with images, resource files, and other important files, they are deployed to the appropriate physical folder on the front-end web servers. This process is handled automatically by the solution deployment mechanism of SharePoint. For example, user controls are deployed to %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\ControlTemplates (or a subfolder), which is mapped to the virtual directory _controltemplates.
  
  

• SharePoint has its own installation and deployment model. For more information, see SharePoint Deployment Models later in this article.
  
  
• SharePoint makes a distinction, unknown in ASP.NET, between application pages and site pages. For more information, see Pages, Parsing, and Safe Mode later in this article.
  
  
• SharePoint has its own systems for modifying web.config files. For more information, see Working with Web.config Files.
  
  
• The ASP.NET worker process model is modified in SharePoint. See Process and Execution Trust Model later in this article.
  
  

Note:

The terms "solution" and "feature" are familiar in software development. The first thing to note about the SharePoint deployment model is that these terms are names of formal components of SharePoint that are defined in this section. By convention, "Feature" is capitalized when it refers to the SharePoint component of that name. Throughout this article, I will follow the additional convention of italicizing "farm solution," "sandboxed solution," and "solution" when the SharePoint component is being referenced. When either "solution" or "feature" is lowercase and not italic, it is being used in its ordinary sense.

 

1. Adding: A solution package file is added to one of two stores.
   
   
   • Farm solutions are deployed by farm administrators to the farm's solution store, which is in the farm's configuration database. This is done by using either the SharePoint Management Shell or the object model.
     
     
   • Sandboxed solutions are deployed to a specific site collection's Solution Gallery by a site collection administrator. The gallery is a special SharePoint list, so it is in the content database. Solution deployment to the gallery is done through the Site Actions UI of the site collection or by using SharePoint Management Shell. For information about the difference between site collections and websites, see Middle Level Object Model later in this article.
     
     
   Thus, SharePoint Solution Package files are never installed to the file system of any server, although elements of a farm solution may be installed to the file system when the solution is deployed.
   
   
2. Deploying: The solution package is unpacked and its elements are deployed to their appropriate places.
   
   
   • For a farm solution, this step also requires a farm administrator and can be done by using either Central Administration or SharePoint Management Shell, or the object model. Some examples of how elements are deployed: user control files (.ascx) are copied to %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\ControlTemplates and assemblies are deployed to the global assembly cache or to a web application's \bin folder. If there are SharePoint Features (defined later) in the farm solution, they are in this step copied to a subfolder of %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES.
     
     
   • For sandboxed solutions, the deployment step is taken by a site collection administrator. There are limits on what kinds of elements can be in sandboxed solutions and where they can be deployed. For example, nothing can be deployed to the file system of the servers from a sandboxed solution. Features in sandboxed solutions are deployed to the content database.
     
     
   It is also in this second step that any Features in the solution are installed in the Feature Gallery of the farm, web application, site collection, or website, depending on the scope of the Feature. (For more information about the relations of farm, web applications, site collections, and websites to one another, see Content Hierarchy later in this article.)
   
   

Note:

SharePoint is not consistent in its terminology with regard to installation. The terms adding, deploying, and activating are the most frequently used to refer to the three steps of installation; but depending on what tool is used to complete a step and whether the solution is farm or sandboxed, you will see a variety of terminology. The first step may be called adding, installing, or uploading. The second step may be called deploying, activating or installing. There is a similar inconsistency in the terms for reversing these steps; but most commonly, reversing the second step is called retracting and reversing the first step is called removing. The third step, which applies only to Features, is always called activating, and its reversal is always called deactivating.

 

• The script files that define the JavaScript object model are downloaded to a client computer when a page that references them is opened.
  
  
• Similarly, a Silverlight .xap executable is downloaded to the client computer when a page that is hosting it is accessed. The SharePoint assemblies that contain the Silverlight client object model are encased in the .xap file. Those assemblies are Microsoft.SharePoint.Client.Silverlight.dll and Microsoft.SharePoint.Client.Silverlight.Runtime.dll. (It is also possible to cache these assemblies on the front-end web server. For details, see RIA Technologies: Benefits, Tradeoffs, and Considerations.)
  
  
• Stand-alone .NET Framework applications (such as a WPF application) that target the SharePoint client object model are installed just as any other client applications: using MSI files or ClickOnce. The assemblies that contain this client object model, Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll, must be distributed as part of the solution. The redistributable is located at SharePoint Foundation 2010 Client Object Model Redistributable.
  
  

Worker Processes, Farm Solutions, and Sandboxed Solutions

When an HTTP request is received by a front-end web server, a special driver, HTTP.SYS, detects the request and routes it to the application pool that is handling requests for the targeted IIS website, and thus, the targeted SharePoint web application. Every application pool has an IIS worker process (w3wp.exe) in which the request pipeline for each request is executed. (For more information about the IIS 7.0 worker processes and application pools, see Introduction to IIS 7 Architecture.) On a SharePoint server, the IIS worker process runs in the application pool account, which gives the process read and write permissions to SharePoint resources. On a multiserver farm, the application pool account is a domain user that is not a machine administrator on any server in the farm, but is a member of the WSS_WPG, WSS_ADMIN_WPG, and IIS_USERS groups on each server. (This should be a different account from the farm administration account. The latter is also not a local machine administrator on any farm server. The farm account is a member of all the same groups as the application pool account and also the WSS_RESTRICTED_WPG_V4 and Performance Monitor User groups. An exception is made for the application pool of the Central Administration web application: its application pool account is the farm account. Also, the SharePoint 2010 Timer Service executes in the context of the farm account.) For more information about the accounts needed in a SharePoint farm, see Plan for administrative and service accounts (Office SharePoint Server).

Figure 4 shows how an IIS worker process that is running on a front-end web server processes an HTTP request.

Figure 4. Request processing model for full-trust farm solution

However, unlike a standard ASP.NET application, SharePoint makes a distinction between sandboxed solutions and farm solutions. Farm solutions run in the IIS worker process just like any ASP.NET application. Sandboxed solutions run in a specially restricted execution environment. This is necessary because sandboxed solutions are installed on (and scoped to) SharePoint site collections without the intervention of the IT professionals that are managing the SharePoint farm. To prevent rogue or poorly performing code from slowing or crashing the application pool, SharePoint imposes restrictions on what the code in a sandboxed solution can do. As a crucial part of the implementation of this system, sandboxed solutions must run in a special sandboxed worker process (SPUCWorkerProcess.exe).

When a request attempts to access a sandboxed solution, a SharePoint execution manager that runs in the IIS worker process finds a sandbox worker process (or starts one, if none is running) in which the code of the sandboxed solution will run. In principal, this sandboxed worker process can be started on any server in the farm that is running the SharePoint 2010 User Code Host service (SPUCHostService.exe). (In the UI of the Central Administration application, this is known as the Microsoft SharePoint Foundation Sandboxed Code Service.)

The server that is running the SharePoint 2010 User Code Host service can be, but does not have to be, the front-end web server on which the IIS worker process is running. Which server is used is configurable in the Central Administration application: Administrators can choose to have each sandboxed process run in "local mode," which means that each request for a sandboxed solution is processed on the same front-end web server on which the IIS worker process is running; or they can have the execution manager start each sandboxed process in "remote mode," also known as "affinity mode." In affinity mode, the execution manager looks for a server that is running the SharePoint 2010 User Code Host service and which already has created an application domain inside its SPUCWorkerProcess.exe process for the very same sandboxed solution. (This would be the case if that same sandboxed solution was requested before, possibly by another user on another site collection.) If there is a matching application domain, the request is sent to that same application domain for handling. If none of the servers that are running the SharePoint 2010 User Code Host service already has an application domain for the sandboxed solution, the execution manager assigns the request to the least busy of those servers. The server then creates the needed application domain and processes the request for the sandboxed solution. The application domain stays alive after the request is processed and is reused if there is another request for the same sandboxed solution.

By default, all sandboxed solutions that are handled by a given server run in the same sandbox worker process, but this is configurable through the object model. Each sandboxed solution gets its own application domain within the common process, and this, too, is configurable through the object model. The SharePoint 2010 User Code Host service runs in an account that has the same rights as a typical application pool account. It should be a member of the WSS_WPG, WSS_ADMIN_WPG, and IIS_USERS groups on the server on which the service instance is running.

Code Execution and Access Constraints on Sandboxed Solutions

All code that runs in this sandbox worker process is subject to execution and access constraints. There are two systems of constraints: One applies to all and only calls to any assembly, except Microsoft.SharePoint.dll, whether it is a SharePoint assembly or not. The other applies to all and only calls made to the parts of the SharePoint Foundation object model that are in the assembly Microsoft.SharePoint.dll. The calls that this second system applies to are not just calls in custom SharePoint solutions. Calls to Microsoft.SharePoint.dll from other SharePoint assemblies (that have themselves been called by custom code) such as Microsoft.SharePoint.Linq.dll are also subject to this constraint.

The first system of is imposed by two mechanisms:

1. A highly restrictive code access security (CAS) policy significantly limits what code in the sandboxed worker process can do. This policy is defined in the wss_usercode.config file in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG, and it is referenced in the web.config file in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode. Among the restrictions imposed by the CAS policy are the following:
   
   
   • Code in the sandbox cannot call unmanaged code.
     
     
   • Code in the sandbox cannot call the Microsoft .NET Framework 3.5 reflection APIs.
     
     
   • Code in the sandbox can call only the .NET Framework 3.5 assemblies that have the AllowPartiallyTrustedCallersAttribute attribute. This blocks access to about two-thirds of all the .NET Framework 3.5 APIs, including System.Printing, for example.
     
     

   Note:
   The CAS policy makes an exception for strong-named Microsoft Office assemblies. These are granted full trust.

    
2. Secondly, the sandboxed worker process has a low-privileged security token.
   
   
   • The token denies the process the right to read from or write to the file system.
     
     
   • The token denies the process the right to call to the network. Therefore, only resources available on the server that is running the sandboxed worker process may be accessed. An external database, for example, cannot be accessed.
     
     
   • The token denies the process the right to write to the registry.
     
     
   • The token denies the right to call to any assembly that is not in the general assembly cache, even if it has the AllowPartiallyTrustedCallersAttribute attribute and would otherwise be eligible to be called from the sandboxed worker process.
     
     

As noted, a second system of constraints imposes restrictions on what APIs in Microsoft.SharePoint.dll can be directly called by code in the sandboxed worker process, and a call to any forbidden API in the object model results in an exception (which is caught and reported to the user as an error). The implementation of these restrictions is accomplished by a pair of specially restricted versions of the Microsoft.SharePoint.dll assembly, sometimes called shim assemblies, that are located in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode\assemblies. One of the two assemblies is loaded by the sandboxed worker process. The other assembly is loaded in a special proxy process (SPUCWorkerProcessProxy.exe) that runs in full trust and that is also managed by the SharePoint 2010 User Code Host. The standard Microsoft.SharePoint.dll assembly is also loaded in this proxy process.

The main job of the two shim assemblies is to filter out forbidden SharePoint classes and members. When the sandboxed solution calls an approved API, the first shim assembly passes it to the second in the proxy process, which in turn passes it to the standard Microsoft.SharePoint.dll. Any returned results are passed back to the original calling code. This cross-process interaction is possible through .NET Framework remoting. A sandboxed worker process and a full-trust proxy process are always started together and paired with one another. If either process crashes, the other is also stopped.

The shim assemblies also have a secondary job. Some SharePoint APIs are available to sandboxed solutions, but only with special restrictions on the parameters that are passed to them. It is the shim assemblies that enforce these input restrictions and ensure that an exception is thrown when there is a violation. The only case of this in SharePoint Foundation 2010 are the SPSite and SPSite constructors. These constructors can be called in sandboxed solutions, but only URLs or GUIDs that refer to the site collection in which the sandboxed solution is running can be passed to them.

Note:

Because the second shim assembly and the standard Microsoft.SharePoint.dll run in a full-trust process, permitted APIs in the SharePoint object model can do some things that would otherwise be forbidden in a sandboxed solution. For example, the GetLocalizedString method can read .resx files even though sandboxed solutions cannot generally read from the disk. (However, a file cannot be deployed to disk in sandboxed solution, so the .resx file would have to be previously installed as a farm solution.)

 

The following are some of the restrictions on the SharePoint object model that can be accessed:

• The SPWebApplication class cannot be accessed. Among other things, this means that a sandboxed solution cannot access anything outside its hosting site collection.
  
  
• Almost all classes in the Microsoft.SharePoint.WebControls namespace cannot be accessed, which means that you are mainly restricted to ASP.NET controls in sandboxed solutions.
  
  

For a complete list of APIs in Microsoft.SharePoint.dll that are available to sandboxed solutions, see Microsoft.SharePoint.dll APIs That Are Available from Sandboxed Solutions.

Important:
The deployment stage of a sandboxed solution itself runs in a sandboxed worker process and is subject to the same execution constraints. For example, you cannot deploy a file to the disk when you are deploying a sandboxed solution. This is the main reason why a user control (ASCX file) cannot be in a sandboxed solution. See SharePoint Deployment Models for information about the deployment stage.

 

Resource Usage Restrictions on Sandboxed Solutions

Sandboxed solutions are also subject to three kinds of resource usage restrictions that can be organized based on the kind of entity to which the restriction applies and the kind of entity on which the penalty for exceeding the restriction is imposed.

• Per Request with the Request Penalized: There is a hard limit to how long a sandboxed solution can take to finish. By default, this is 30 seconds. If a sandboxed solution exceeds the limit, the request (but not the sandboxed worker process) is terminated. (This limit is configurable, but only through custom code against the object model. The relevant parts of the object model cannot be accessed by sandboxed solutions, so no sandboxed solution can change the limit.)
  
  
• Per Request with the Process Penalized: A set of 15 resource limits apply to requests. If a request exceeds one of them, the process (and all the sandboxed solutions that are running in it) is terminated.
  
  
• Per Day/Per Site Collection with the Site Collection Penalized: Each site collection is subject to a configurable maximum of daily resource points. These points accumulate based on an algorithm that takes into account the use of resources in the 15 resource categories by the sandboxed solutions that are installed in the site collection. When a site collection exceeds its maximum allowed points, all sandboxed solutions in the site collection are terminated and no more can run for the rest of the day.
  
  

SharePoint provides a solution validator framework that can be used to develop custom solution validators, such as a validator that verifies whether a solution is signed with a specific certificate. The validators in a site collection run when a sandboxed solution is activated (that is, deployed, in the terminology used earlier in this article). The activation of any invalid solution is blocked. If a validator is updated or a new validator is added, each activated solution is rechecked by the validators the next time it is executed. Invalid solutions are deactivated. For an introduction to custom validators, see Developing, Deploying, and Monitoring Sandboxed Solutions in SharePoint 2010.

For more information about the sandbox restrictions, see Sandboxed Solutions in SharePoint 2010 and its child topics and the Microsoft patterns and practices guidelines for Sandboxed Solutions.

Figure 5 shows how an HTTP request is handled when it accesses a sandboxed solution.

Figure 5. Request processing model for sandboxed solutions

The SPUCHostService.exe, SPUCWorkerProcess.exe, and SPUCWorkerProcessProxy.exe files are located at %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode.

Note:
A solution that is designed to run in the sandbox can be deployed by a farm administrator as a farm solution. It might perform better if it is, because it would run in the IIS worker process instead of the sandboxed worker process.

 

Not all SharePoint execution is in an IIS worker process, a sandboxed worker process, or the proxy process. The following are some examples:

• The SharePoint Timer Service (owstimer.exe) runs on all servers and is used to execute prescheduled timer jobs. It runs under the farm account.
  
  
• The SharePoint Tracing Service (wsstracing.exe) runs under the local service account.
  
  
• The SharePoint Administration Service (wssadmin.exe) runs under the local system account.
  
  

Within the category of farm solutions, a further distinction can be made when the requested resource is an .aspx page. If the requested page is what SharePoint calls an application page, the returned page is passed to the regular ASP.NET page parser; but if the requested page is what SharePoint calls a site page, the returned page is routed through a special safe mode parser. The distinction between the two kinds of parsing is best understood in light of the distinction between the two kinds of pages. For more information about both subjects, see Pages, Parsing, and Safe Mode later in this article. (Application pages cannot be included in sandboxed solutions. All pages installed as part of a sandboxed solution use safe mode parsing.)

Assembly Deployment, Execution, and Persistence

Farm solutions divide into two types depending on where their assemblies are deployed and the trust level of the assemblies' execution:

• GAC/Full Trust: The assemblies are deployed to the global assembly cache (GAC) of every front-end web server in the farm and run with full trust. They are callable from any SharePoint web application on the farm.
  
  
• Bin/CAS: The assemblies are deployed to the \bin folder (on every front-end web server) of a specific SharePoint web application and their trust level is determined by a CAS policy referenced in the web application's web.config file. They have to be separately deployed to every SharePoint web application that needs to call them.
  
  

  Tip:
  We recommend that you use the Bin/CAS model only when neither full-trust farm solutions nor sandboxed solutions (nor the hybrid solutions described in Hybrid Solution Techniques) are possible for your solution.

   

Noncompiled files for both kinds of farm solutions—including, for example, images, user controls, and string resources—are deployed to subfolders of %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\.

Sandboxed solutions are deployed inside a SharePoint solution package (.wsp file) to the Solution Gallery of a specific site collection. Thus, they are deployed and persisted in the site collection's content database. As noted earlier, they do not run in full trust: Instead, they run within a highly restricted CAS policy and can only call a restricted subset of the SharePoint object model. A sandboxed solution can be accessed only in site collections to which it is deployed.

When a sandboxed solution is accessed for the first time, such as when a user navigates to a page that contains a Web Part from a sandboxed solution, any assemblies in the solution are unpacked from the solution package and copied to the file system of the server that is handling the sandbox request. The default location is C:\ProgramData\Microsoft\SharePoint\UCCache, but this is configurable on each server that is running the User Code Host Service. (Recall that the server that handles the sandbox request is not necessarily the front-end web server that is handling the initial HTTP request. The User Code Host Service can be run on back-end application servers in the farm instead.) Because the sandboxed worker process cannot copy anything to the file system, the copying is done by the User Code Host Service.

The assemblies do not stay in the file cache perpetually. When the user session that accessed the assemblies finishes, the assemblies stay in the cache for only a short time, and they may be reloaded from there if another user session accesses them. Eventually, if they are not accessed, they are removed according to a proprietary algorithm that takes into account how busy the server is and how much time has gone by since the assemblies were last accessed. If the sandboxed solution is used after that time, the assemblies are unpacked again and copied to the UCCache.

Caution:
Administrators, developers, and third-party code should not add, remove, or load anything from the UCCache. It should be accessed only by the SharePoint infrastructure.

 

Hybrid Solution Techniques

The SharePoint solutions architecture includes a technique by which a sandboxed solution can call custom operations that run in full trust. The technique requires that a farm solution be developed that includes one or more classes that derive from SPProxyOperation. Each of these defines an operation that will run in full trust and can be called from sandboxed solutions by using the ExecuteRegisteredProxyOperation method. Specifically, these full-trust proxy operations execute in the same proxy process (SPUCWorkerProcessProxy.exe) that was described earlier in Worker Processes, Farm Solutions, and Sandboxed Solutions. The proxy operations can return data to the sandboxed solution.

Like all farm solutions, the assembly with the proxy operations can be deployed only if it is from a trusted source.

Figure 6 shows how a request that accesses a sandboxed solution is processed when the sandboxed solution makes a call to a full-trust proxy.

Figure 6. Request processing model when a sandboxed solutions calls a full-trust proxy

The preceding description might give the impression that, with the hybrid technique, a farm solution and a sandboxed solution are always developed together by the same development team. In fact, the farm solution may be developed specifically to provide certain operations to any and all sandboxed solutions that need those services, including sandboxed solutions that are developed by other teams. For example, because a sandboxed solution cannot write to the SharePoint Unified Logging Service (ULS) logs, a farm solution that opened proxy logging operations to sandboxed solutions would be very useful.

Another hybrid technique uses client-side code to access the resources that cannot be accessed from a sandboxed solution. For example, a sandboxed solution could include a custom site page with JavaScript that makes calls to the SharePoint JavaScript client object model. Also, a sandboxed solution could include a Web Part that hosts a Silverlight application. The latter application can make calls to the SharePoint Silverlight client object model. For more information about the client-side code in SharePoint, see Client Object Models in SharePoint later in this article.

For more information about hybrid solution techniques, see Hybrid Approaches.

• Typical purpose: Application pages tend to be function-oriented, especially functionality that is needed by many kinds of websites within a given web application; for example, the standard form for creating a new list item is an application page. Site pages tend to be content-oriented; for example, the list-of-lists page of a standard team site. However, exceptions to both tendencies are possible. Indeed, we currently recommend that third-party developers develop custom Web Parts, which can be added to site pages, to handle their solution's functionality whenever possible, rather than develop custom application pages.
  
  
• Customizablility: Site owners (and other users who have appropriate permissions) can customize site pages, but not application pages. Users can also add an entirely new ASCX page to a website's Site Pages gallery, but only web application administrators can install a new application page.
  
  
• Class inheritance: Application pages are objects of the LayoutsPageBase class or the UnsecuredLayoutsPageBase class. Site pages are objects of the WikiEditPage class or the WebPartPage class. (All of these classes derive from the ASP.NET Page class.)
  
  
• Web Part support: Application pages cannot have Web Part zones or dynamic Web Parts. They can have static Web Parts, but there is little point to using a static Web Part instead of an ordinary control on an application page because end users cannot customize application pages anyway. Some kinds of site pages can have static Web Parts, and other kinds can have Web Part zones with dynamic Web Parts. See later in this section for more information.
  
  
• Storage location: Application pages are stored on the file system of the front-end web servers in the _layouts virtual directory of a web application (which maps to the %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS physical directory) or one of its subdirectories. A site page that has not been customized is stored in other subdirectories of %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE, most typically in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\SiteTemplates and %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES. A site page that has been customized, such as with Microsoft SharePoint Designer, is stored in the content database of the website for which it was customized. New site pages that have been added to the Site Pages gallery are stored just as customized pages.
  
  

  Note:

  Even an uncustomized site page has an entry in the content database; but whereas the entry of a customized page contains the ASPX markup that constitutes the page, the entry for an uncustomized page contains the path of the .aspx file on the local front-end web server. An uncustomized page can be shared by many websites. If it is, it is referenced in each website's content database, with all the entries pointing to the same physical file. For example, every Team Site has a content database entry pointing to the default Team Site home page. If the home page is customized on any of the sites, it is copied into the page's entry in the content database in its customized form, and the pointer to the uncustomized version is removed. Sometimes the uncustomized site page is referred to as a page template and the pages in the content database as page instances. However, remember that if the page is not customized in a particular website, the "instance" of the page is simply the database entry pointing back to the file on the file system.

   
• Availability: An application page can be accessed from every website in the web application and is therefore shared among all the websites. But a site page is available only to a user of the website where it is deployed. (Uncustomized site pages are shared by multiple websites, as noted earlier, but only websites where they have been specifically provisioned either as part of a Feature or as part of a site definition.)
  
  
• Parsing mode: Application pages are parsed in direct mode, which just means that they are parsed by the standard ASP.NET page parser. The first time an application page is requested, it is parsed and compiled and cached in the front-end web server's memory, where it remains until the application domain or the entire IIS host is recycled. With every subsequent request for the page, it is served from the cache, if it is there. Uncustomized site pages are also parsed in direct mode, but customized site pages, and new pages that are added to the Site Pages gallery, are parsed in safe mode. Safe mode processing differs from direct mode (that is, from standard ASP.NET page processing) in the following ways:
  
  
  • Only controls (including Web Parts) that are registered as safe in the web application's web.config file are rendered.
    
    
  • Inline server-side code is not allowed in safe mode, and an error page is returned to the user if the safe mode parser finds inline code on the requested site page. Inline code includes <script> elements, such as <script runat="server"> [code is here] </script>, and control event handlers, such as <asp:button OnClick="MyButtonHandler()" />. (Code behind that is compiled into a separate assembly is allowed, and so is embedded JavaScript.)
    
    
  • The page is not compiled. (And, thus, any compilation directives in the file are ignored.)
    
    

  Note:
  The terms safe mode parsing, safe mode processing, and safe mode rendering are used interchangeably in SharePoint documentation.

   

Security Note:

It is possible to allow inline code, unsafe controls, or both, on selected customized site pages. You can do both things by adding one or more <PageParserPath> elements to the <SafeMode> element of the <SharePoint> section of the web application's web.config file. You can use the attributes of the <PageParserPath> element to specify a customized site page or set of customized site pages, and to enable inline code and unsafe controls for the designated site pages. However, you should use extreme caution when you make these kinds of changes, because they cancel the security benefits of safe mode. For example, if you allow inline code for all pages that have names on the pattern Contoso*.aspx in the directory /sites/contoso/SitePages, anyone with the right to add pages can create a page that has a name following that pattern and add it to that directory, including a page that contains malicious or poor-performing code. (The directory path is a "virtual path" that points to a set of files in the content database.) Notice that allowing unsafe controls only enables such controls that are added in an editing tool, such as SharePoint Designer. When an end user adds a Web Part to a page in the browser, the Web Part must still be registered as safe even if unsafe controls have been enabled in a <PageParserPath> element. You can turn on compilation for selected customized site pages by using an attribute of the <PageParserPath> element. This might be useful if you have reason to believe that the customized page will be visited often enough to justify compiling it into a DLL cached in memory.

 

Lists

Content Types and Field Types

External Lists and the Business Connectivity Service

External data, such as data in an SAP installation or Oracle database, can also be represented as a list on a SharePoint Foundation page and within SharePoint Workspace and Microsoft Office client applications. The Microsoft Business Connectivity Services (BCS) of SharePoint Foundation enables read/write access to this data.

The critical components of BCS are Business Data Connectivity (BDC) service models. Each model is an XML file that describes a type of external data source, such as SAP services. One or more specific instances of the data source, such as a particular SAP database, are defined in the model, including connection and security information about the data source. The business entities in the data source, such as Customer or Order, are represented in the model by external content types, and the model also defines relationships between these entities. Finally, the model defines, for each entity, a set of standard operations, called stereotyped operations, that can be performed on the entity, including create, retrieve, update, and delete operations. For more information about the structure of BDC models, see BDC Model Infrastructure. The models are stored in a dedicated database on the SharePoint farm computer that is running SQL Server, which is distinct from the configuration database and the content databases. This database is called the metadata store.

After a model is added to the metadata store, users can access the external data in a variety of ways. For example, in SharePoint Foundation, users can create a SharePoint list out of an external content type, such as Customer, or add a column of data from the external source to an existing list. SharePoint Server 2010 has some BCS enhancements: It includes some built-in Web Parts for working with external data, and it enables users to search the external data. Also, SharePoint Workspace and Microsoft Office client applications can access and display the external data directly. Finally, with SharePoint Server 2010, users can index and search the external data sources.

A service named Business Data Connectivity service manages the interactions between SharePoint and the external data source. The service runs on an application server in the farm. There is also a BDC Runtime that runs on all front-end web servers. When a SharePoint client application requests external data, the BDC Runtime on the front-end web server requests the metadata that defines the BDC model from a locally cached copy of the BDC metadata store. The runtime then uses the metadata provided to perform data operations directly on the external system. Similarly, on client computers that are running SharePoint Workspace and Microsoft Office client applications, a BDC Client Runtime enables direct client access to the external data by using the BDC model, which is also cached on the client computer (although the SharePoint Server 2010 farm is still needed for long-term persistence of the BDC models). The external data itself can be cached on the client computer to enable an offline experience.

After the BDC service is running and the needed BDC models are registered, end users can create non-code solutions that involve external data. For more complex solutions, the BCS Runtime APIs enable developers to make custom Web Parts or other solutions to interact with the external data. Because a BDC model provides a kind of translation between operations in code and the stereotyped operations of the external data source, the same APIs can be used for all external data sources no matter how different their individual access systems are. BDC solutions are packaged and deployed as farm solutions.

Figure 7 shows some of the major components of BCS and their relationships.

Figure 7. BCS runtime and deployment components

The BDC service is built in conformance with the Service Application Framework of SharePoint Foundation. See also Services and the Service Application Framework and Services Hierarchy later in this article.

For more information about BCS architecture, see BDC Architecture, Mechanics of Using Business Connectivity Services, Business Data Connectivity (BDC) Service, and External Data in SharePoint 2010.

• Windows Services
  
  
• Web Services
  
  
• IIS Web Services
  
  
• Configuration Services
  
  

• Web services that implement the Service Application Framework are represented with a dot-bordered box. At initial installation, each has a single CFSI, sometimes called a "service application".
  
  
• The service proxies belong to the farm, but each CFSI proxy (also known as a service application proxy) belongs to a web application. The content publishing web application and the Central Administration web application each have their own proxy for the Business Data Catalog CFSI, and they each have their own for the Usage and Health Data CFSI. Neither has a proxy for the Subscription or Application Discovery and Load Balancer CFSIs at initial installation.
  
  

User Security

Code Security

Physical Objects Hierarchy

Content Hierarchy

The Content Hierarchy includes classes that represent publishable items of data, such as list items. There are also classes that represent nested containers of data, such as lists, content databases, websites, site collections, and web applications.

High Level Object Model

Beneath the farm, the broadest content container is the web application, which is represented by the SPWebApplication class. An SPWebApplication object represents a content-publishing web application in SharePoint Foundation. It contains one or more content databases, which hold the data of one or more site collections. Each such web application is served by at least one (and usually only one) IIS website and typically has its own application pool in IIS. Also, each web application has its own security and authentication settings. The SharePoint Foundation object model provides some hooks into the web application's other life as an IIS object through the IisSettings and ApplicationPool properties. For more information about the relation between SharePoint web applications and IIS, see SharePoint as an ASP.NET-IIS Application earlier in this article.

The SPWebApplication class has a ContentDatabases property that holds all its child content database objects.

Every web application contains one or more content databases. Each of these is represented by the SPContentDatabase class. A content database is a SQL Server database that contains all the data (lists, list items, blog posts and comments, wiki pages, and documents in document libraries) and the customized page files that constitute the site collections that belong to the database. Objects that represent each child site collection are in the Sites property.

Both SPWebApplication and SPContentDatabase inherit from SPPersistedObject, so these objects persist in the farm's configuration database.

For more detailed discussions of web applications, content databases, and their classes, see The Content Hierarchy of Microsoft SharePoint Foundation and Background: Content Entities in Microsoft SharePoint Foundation.

Middle Level Object Model

At the middle level of the content hierarchy are site collections and their subsites. An SPWeb object represents a single website. An SPSite object represents a collection of websites within a SharePoint web application that are grouped together for mainly administrative reasons. (The SPSite class is not a collection in the sense of a class that implements ICollection.)

The SPSite class has a RootWeb property that holds its child top-level website. (Top-level websites were called "root webs" in the first version of SharePoint Foundation, Microsoft SharePoint Team Services.) In turn, the SPWeb object that represents the top-level website has a Webs property that holds all its immediate child subsites (but not the subsites of those subsites). (The AllWebs property returns all the descendent sites and the top-level website.)

Among the SharePoint elements that can be scoped to the site collection level are master pages, Web Parts, themes, lists, content types, and Features. A site collection can also be a unit of backup and restoration. It is also the level at which groups of users are created and assigned default permissions. Site collections are the largest possible scope for a search in SharePoint Foundation, although broader search scopes are possible in SharePoint Server 2010.

The content of a site collection is always included within a single content database.

Websites can be children of other websites, and all websites belong to a site collection. The SPWeb class has dozens of properties and methods for programmatic handling of every aspect of the website, including users, lists, fields, content types, Features, alerts, and much more.

For much more information about site collections and websites, see Building Block: Websites and Site Collections, The Content Hierarchy of Microsoft SharePoint Foundation, and Background: Content Entities in Microsoft SharePoint Foundation.

Tip:

Both SPWeb and SPSite evolved from early versions of what is now called "SharePoint" before there was a .NET Framework. Even today they wrap some COM objects. The .NET Framework garbage collector does not know how to release these COM resources. Accordingly, both classes implement the IDisposable interface. If they are not disposed of, website and site collection objects cause memory leaks on the farm servers. It is essential that SharePoint developers call the Dispose method of every SPWeb and SPSite that their code creates. There are some subtleties about disposing of such objects. For example, website and site collection objects that are obtained from the SPContext object should not be disposed of. Developers should carefully study Disposing Objects.

 

Low Level Object Model

At the heart of SharePoint are lists and list items, which are represented, respectively, by the SPList and SPListItem classes. The SPList class has members for programmatically adding, deleting, and retrieving list items, and also for managing metadata about the list such, as its content types and fields. The SPListItem class has members for managing the item's fields, the values of its fields, its content type, and any associated workflows. Lists can have folders that give them a hierarchical structure. Folders are represented by the SPFolder class.

Note that, although any given list item has a specific content type, the object model provides only the SPListItem class to represent all list items. Hence, working with list items and their fields is, in many ways, like working in a weakly typed environment. SharePoint includes a tool, SPMetal, that can generate code for an object relational mapping. The generated code defines classes for each content type in a website and, for each field in the content type, it declares a strongly typed property. The tool makes it possible for LINQ queries to be strongly typed. For example, if a developer mistakenly refers to the DueDate field of the Task content type as "DateDue", the compiler catches the mistake if SPMetal is used and the reference is to a property of a Task type object, myTask.DateDue. However, without SPMetal, the reference would have to be to a member of the fields collection of an SPListItem object, myItem["DateDue"]. The mistake would not be caught until run time.

Each field (column) on a list item is represented by an SPField object.

For more information about lists, list items, folders, and fields, see Building Block: Lists and Document Libraries, Building Block: Columns and Field Types, and SharePoint List Data Model.

Services Hierarchy

The Services Hierarchy includes classes that represent web services, Windows services, other types of services, instances of services, and CFSIs of services (see Services and the Service Application Framework earlier in this article).

A SharePoint Foundation service is represented by a class that inherits from SPService. The class provides members that get information about the jobs the service is performing. If a service implements the Service Application Framework, the SPService object has an Applications property that holds all the CFSIs of the service that are running on the farm. A CFSI of a service is represented by an object of a class that inherits from the SPServiceApplication class.

Every SPService object has an Instances property that holds all the instances of the service that are running on various servers in the farm. The instances that host a particular CFSI are held in the ServiceInstances property of the SPServiceApplication object that represents the CFSI. No more than one instance of each CFSI runs on any one server. However, a given service can have multiple CFSIs, and they can run on the same servers. Moreover, a given CFSI (and, thus, a given service) can run on multiple servers, in which case each server has its own actual instance (a running process) of the CFSI. If the service has no CFSIs, it still has instances on each server on which it runs, but there can be no more than one instance of such a service on a given server. Each instance is represented by an object of a class derived from SPServiceInstance.

Applications that consume services that conform to the framework are represented by proxies. Here, also, there is a proxy object for the service as a whole and a proxy for the particular CFSI that is being consumed. The consumer proxy for a service is represented by an SPServiceProxy object and the proxy for the CFSI is represented by an SPServiceApplicationProxy object.

Figure 10 illustrates the relationships among the main classes in the Service Application Framework.

Figure 10. Relation of major classes in the Service Application Framework

The following kinds of objects are persisted in the configuration database because these classes inherit from SPPersistedObject:

• SPService
  
  
• SPServiceApplication
  
  
• SPServiceInstance
  
  
• SPServiceProxy
  
  
• SPServiceApplicationProxy
  
  

For more information about the services object model, see The Services Hierarchy of Microsoft SharePoint Foundation and Background: Service Entities in Microsoft SharePoint Foundation.

Note:
The Silverlight client object model in SharePoint is not supported on Windows Phone 7.

 

• Using the SharePoint Foundation 2010 Managed Client Object Model
  
  
• Using the SharePoint Foundation Client APIs
  
  
• SharePoint 2010 Client Object Model
  
  
• SharePoint 2010 Client Object Model Hierarchy and Identity
  
  
• Client Context as Central Object
  
  
• Client Application Models in SharePoint 2010
  
  

Note:

The client object models are not the only way to query SharePoint list data from a client application. SharePoint also supports a WCF Data Services (formerly ADO.NET Data Services) interface to the list data. For more information, see Data Model, Data Management, and Query System earlier in this article. The section Low Level Object Model earlier in this article mentions that the server object model treats content types and their field types in a weakly typed manner, but that the SPMetal tool enables strongly typed programming against these entities. A parallel point applies to client-side computing: Content types are weakly typed in the client object model, but they are strongly typed when you are programming against the WCF Data Services interface.

 

Note:
SharePoint Designer envisages two Reusable and Globally Reusable workflows. These are really just list workflows that you can use on multiple lists without having to re-create them for each of those lists.

 

• Name and description of the workflow
  
  
• Class within the workflow assembly to call
  
  
• Identity of the workflow assembly
  
  
• Location of any custom forms used in this workflow
  
  

• SharePoint 2010 Developer Center
  
  
• Microsoft SharePoint 2010 SDK (online)
  
  
• Download: SharePoint 2010 Reference: Software Development Kit
  
  
• Download: Microsoft SharePoint Foundation 2010
  
  
• Download: Microsoft SharePoint Server 2010
  
  
• SharePoint 2010 Development Basics Technical Articles