An Overview of the SharePoint Platform for ASP.NET Developers

When ASP.NET developers begin to learn about SharePoint development, they find many familiar concepts. SharePoint is built on top of the ASP.NET framework and uses many ASP.NET features including Web Parts, Web Part zones and master pages, security providers, session state managers, and user controls on ASPX pages. ASP.NET developers can view SharePoint as an extension of a framework that they already know.

SharePoint has two distinct layers. The base layer, which is named Windows SharePoint Services (WSS), is built on top of the ASP.NET framework. It provides the foundation for the ready-to-use collaborative application capabilities that are standard in SharePoint. It is also the foundation for custom Web-based portal and collaborative business applications. Windows SharePoint Services 3.0 is licensed as a component of Windows Server 2003 and Windows Server 2008. Microsoft Office SharePoint Server 2007 builds on top of ASP.NET and Windows SharePoint Services to provide enhanced core services and functioning, extensible applications that are meant for information workers.

The following illustration shows the SharePoint development platform.

The SharePoint development platform

There are many types of functionality available in SharePoint, particularly if you combine what is available in Windows SharePoint Services with what is available in Microsoft Office SharePoint Services. This topic focuses on the concepts that explain the core services. These services form the foundation for both standard and custom SharePoint applications. For more information, see Introduction to SharePoint Products and Technologies for the Professional .NET Developer on MSDN.

Information Hierarchies and Content Types

Two key concepts in SharePoint are containment hierarchies and content types. Containment hierarchies store and manage information and applications. The containment hierarchy for SharePoint is, from the top to the bottom, the farm, the Web application, the site collection, the site, the list and libraries, and the list items and folders. A containment hierarchy relates to a logical hierarchy that overlays a physical set of resources. For example, a farm is a grouping of physical resources that includes Web front-end servers, databases that provide logical application services (in SharePoint, these are termed shared services) along with configuration data, and a set of farm level management capabilities. The entire set of applications in the farm use these resources. For information about how the logical hierarchy relates to the physical topology, see Server and Site Architecture on MSDN.

Web applications are contained in a farm and correspond to the Internet Information Services (IIS) application pools that run on each Web front-end server in the farm. Web applications contain configuration data and provide a database boundary. A Web application also contains one or more site collections.

A site collection provides a data boundary, a scale boundary, an administrative boundary, and a permission boundary in the Web application. The site collection is a scale boundary as well because it is the smallest unit that is managed across databases. A site collection must be in a single database, but a Web application can have multiple databases for all the site collections it contains. A site collection contains a group of sites that are maintained in a hierarchy. The root site is termed the top-level site (it is also often termed the root Web). Sites are similar in concept to virtual directories in ASP.NET, although they are not equivalent. A site contains more functionality and is not actually a virtual directory. For example, in SharePoint, pages for a site are often rendered by merging file-based definitions, page templates, and content from the content database. This type of page is termed a site page or content page. The template can either be defined in a file or stored on the content database. SharePoint has application pages in addition to site pages. Application pages (these are also known as _layouts pages) are conventional ASP.NET pages that are available to all SharePoint applications, and are less typical in a SharePoint application. For more information, see the related discussion in SharePoint Architecture and SharePoint Page Types on MSDN.

The logical hierarchies establish default behaviors for areas in SharePoint such as navigation and information presentation. A newly created SharePoint site is a reflection of a set of data that represents the site instance in the content database. Sites can contain subsites and sites also typically contain lists. Lists are a basic construct in SharePoint for containing, managing, and displaying information. Document libraries are considered a specialized type of list. Lists contain list items and folders.

Generally, with ASP.NET applications, a URL is a reflection of the files in your solution, and the URL typically refers to physical files in the Web site. It is not as straightforward in SharePoint. The URL is based on configured relationships that combine Web applications, site collections, and a hierarchy of contained sites as they are defined in the content database, although it is possible to override the default URL structure with managed paths. For information about the URL hierarchy and the relationship between the SharePoint logical and physical architectures, see Site Collections and Web Applications, SharePoint Architecture and Server and Site Architecture on MSDN.

The site hierarchy is also an important element in a SharePoint application's information architecture. The site hierarchy establishes a site's navigational structure and URL structure. A logical information architecture leads to sites that are more intuitive to navigate and are easier to partition and scale as the sites grow. Although many aspects of the information hierarchy are determined by IT professionals instead of developers, the decisions that developers make often will direct (or limit) the decisions made by IT when they deploy the application or capability. Therefore, understanding information architecture is an important aspect of developing well-designed SharePoint applications. For a scenario-driven overview of how to develop an information architecture, see Information architecture in Office SharePoint Server on TechNet; this article is intended for both IT professionals and developers.

A concept that is related to the information architecture is content types. Content types are metadata that describe the attributes and actions associated with an entity that is managed within SharePoint. For example, a legal firm may create a content type named Contract. The attributes of the Contract content type define the metadata you want to associate with a document that is an actual contract. You might also want to associate workflows with the content type. These workflows run when a Contract document is created within a document library. Content types are powerful because they can be centrally managed, reused, and applied across different types of artifacts within SharePoint. For example, a content type can be associated with a list or attached to a document library. You must plan your content types in order to develop a logical information architecture. For more information about content types, see Plan content types on TechNet**.**

Deploying Applications to a Farm

SharePoint provides a scalable, shared infrastructure for deploying applications to a farm. You set up the farm once, add capacity as needed, and continue to add applications to the shared infrastructure. You only need to maintain one physical infrastructure for all SharePoint applications. However, using a distributed, shared infrastructure has its consequences. For example, it is more difficult to use Web.config files to manage configuration in SharePoint applications than in other types of applications. It is generally preferable to use the configuration mechanisms that are provided by SharePoint.

Although there are many concepts related to managing and deploying applications, this topic focuses on two of them: solutions and features. Both solutions and features help you to manage and deploy multiple applications that are within the SharePoint infrastructure.

SharePoint solutions are often referred to by their .wsp file name extension. Web solution packages (WSPs) package solution artifacts for an application or capability (in many cases, the artifacts do not comprise an entire application). WSPs are CAB files that contain a directory structure and definition files that are understood by the SharePoint deployment infrastructure. SharePoint imports the solution into the SharePoint store and then deploys it to the farm. In addition to the directory and definition files, a WSP primarily contains a set of features. A SharePoint feature is a logical unit of functionality and is self-contained.

SharePoint uses the definition files that are part of the WSP to determine artifacts should be deployed, where they should be deployed within the infrastructure, what configuration actions need to be taken, and what configuration information needs to be created.

For example, when a solution is deployed, SharePoint puts the files, such as pages, user controls, style sheets, and master pages, into the appropriate locations for each Web front-end server. It also deploys assemblies to the global assembly cache on each Web front-end server, installs SharePoint features, and makes configuration updates that indicate the availability of the newly deployed features and site definitions to SharePoint administrators. For more information about SharePoint site definitions and features, see Using Site Definitions.

Solutions also can be retracted. In this case, all artifacts are removed from the file system and all assemblies are removed from the global assembly cache. However, the data that is related to the retracted solution, such as instanced data from an activated feature, remains in the content database even after the related solution is retracted. If the solution is reinstalled and the SharePoint features are reactivated, the site instance becomes available again. For more information, see Deployment Scenarios.

Understanding how SharePoint solutions and features build a SharePoint application is important. You should take the time to understand them before you begin your first SharePoint application.

Site Definitions and Features

Defining an application template instead of an instance of an application itself is another important SharePoint concept. When you define an application template, you are creating a standardized form that dictates how an instance of the application is provisioned. This differs from traditional ASP.NET development where you create a unique instance of an application that you expect to provision and operate in isolation.

The following illustration shows the concept of provisioning.

Provisioning capabilities

Note that the unit to provision can be smaller than an application. This is why it is represented as a capability instance in the diagram. In SharePoint, a feature is equivalent to a capability. This is shown in the following illustration.

Feature activation

A site definition is a template that contains the instructions for creating a site instance. Use a site definition as a collection of references to features that will be activated on the site when it is created. Use features to package related capabilities instead of defining the capabilities directly within the site definition. For example, if your application needs a list, include the list definition in a feature instead of putting it in the site definition. Features provide discrete modules of functionality that can be upgraded, in contrast to site definitions, which cannot be altered after they are deployed. The following illustration shows some of the types of artifacts that are found within a feature and the recommended relationship between features and site definitions.

Features and site definitions

A site definition only refers to a set of features. Features exist independently of any site definition. An effective way to think about a feature is as a blueprint for a capability, while a site definition is a blueprint for a site. Simpler applications may be defined by a single site definition and have a set of features that are activated on the site when it is created. More complex applications may have multiple cooperating sites and features that are activated outside the scope of a site.

Typically, a feature contains multiple elements that work together to implement it. For example, a feature can define a custom list and an associated Web Part. Features support the reuse of capabilities by different applications, and they make managing and versioning capabilities easier. Features can be activated with the site definition when a site is created and provisioned, or they can be activated later on a site that already exists. New instances of a site are provisioned either through SharePoint Central Administration or with a command line utility that is named STSADM.

The Training Management application demonstrates how to use features. When a feature is activated on a blank site, information is created in the content database that directs SharePoint to attach the set of lists and capabilities that are included in the Training Management feature to that site.

The Training Management application includes a site definition that contains the Training Site feature. This creates the site and activates the feature, which provisions the site. The Training Management application also has feature dependencies. There are site collection-scoped features that must be activated before activating the Training Management feature.

The following diagram shows what a Training Management site looks like before and after a feature is activated.

Training Management application feature

Activating a feature does not deploy any bits or files. Only deploying a solution deploys files to the file system. Activating a feature creates information in the SharePoint database stores, such as the configuration database and the content database, that lets SharePoint know that an instance of the feature is present.

Features should be carefully designed. Managing a SharePoint farm with illogically organized features can be chaotic. Conversely, properly designed features are very helpful to the IT professionals who administer the farm. For more information about features and templates, see Features and Templates.

Post-Development Application Customization

SharePoint allows non-developers to construct an application by composing and customizing solution artifacts that developers provide. (Examples of artifacts that can be customized are master pages, styles, and page layouts.) The ability to customize solution artifacts that a developer has already defined will be unfamiliar to most ASP.NET developers. Developers need to understand what artifacts can be customized and how. Architects need to work with their IT counterparts to establish customization policies in order to control how applications evolve as well as what customizations will be preserved when an application is upgraded. The following illustration shows a generic model for how SharePoint manages customizations:

Managing customizations

In this model, the default implementation of an artifact is defined by the application developer. If the artifact is uncustomized, the implementation resolver sends it to the realized implementation. However, if the artifact is customized, the implementation resolver detects this, retrieves it from the customization store, and provides the customized version to the realized implementation at run time. In ASP.NET, this pattern uses a resolver that is named a virtual path provider.

The SharePoint implementation of a virtual path provider determines if a customized version is in the content database. It uses the customized version if there is one. Otherwise, it uses the file-based version. The following illustration shows a SharePoint virtual path provider.

SharePoint virtual path provider

Users and IT professionals use the SharePoint Designer tool to create customizations and save them to a content database. Although SharePoint now uses the terms uncustomized and customized, you might also hear the older terms of ghosted and unghosted. For more information, see Defining Artifact Terminology. The following illustration shows how SharePoint uses and extends ASP.NET capabilities to compose pages.

SharePoint page composition

This diagram is a good example of how SharePoint builds on and extends ASP.NET capabilities. On the right, the page is built from ASP.NET building blocks, such as master pages, Web Parts, Web Part zones, and cascading style sheets. Navigation providers and security providers also use the ASP.NET building blocks. SharePoint extends these capabilities with the ability to inject additional configuration-defined items, such as menus entries, master page customizations, and style customizations.

This section is a brief description of the many ways that non-developers can customize a SharePoint application. Developers must understand how their components can be customized. They should work with architects and IT professionals to put a customization policy in place. For more information about customization, see Understanding and Creating Customized and Uncustomized Files in Windows SharePoint Services 3.0 on MSDN.

For a detailed discussion of the relationship between developed and customized artifacts, see Defining Artifact Terminology.

Home page on MSDN | Community site