Finding Developer Help for SharePoint Products and Technologies
Summary: Discover where to find the SDKs, peer-to-peer forums, MSDN developer centers, and Microsoft TechNet resources you need as you develop with Microsoft SharePoint Products and Technologies. (10 printed pages)
Andrew Connell, Critical Path Training, LLC (Microsoft MVP)
Applies to: Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007
Understanding the Challenges of Multiple SharePoint Resources
Using Resources Available for SharePoint Developers
Finding Documentation and Resources: Best Approach
Finding the SharePoint Development Topics You Need
Understanding the Challenges of Multiple SharePoint Resources
The business community has rapidly adopted Microsoft SharePoint Products and Technologies, which include Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. While SharePoint Products and Technologies offer a long list of features and capabilities with the default installation, the platform is also extensible and customizable and can satisfy even the most complex business requirements. Fortunately, SharePoint Products and Technologies are built on the Microsoft .NET Framework. Therefore, developers with .NET Framework experience and skills can take advantage of a familiar programming environment and set of development tools to extend the platform.
Windows SharePoint Services 3.0 and Office SharePoint Server 2007 are constructed in a stacked architecture, with the Microsoft .NET Framework 3.0 acting as the foundation. Windows SharePoint Services 3.0 is built on top of Microsoft ASP.NET 2.0, and uses many of the components that ASP.NET 2.0 has to offer. Nearly everything that is available to ASP.NET 2.0 developers—such as master pages, user and server controls, the ability to cache custom HTTP handlers, and modules—is available within Windows SharePoint Services 3.0. Windows SharePoint Services 3.0 hooks directly into the ASP.NET 2.0 page life cycle through a custom HTTP application, handlers, and modules. In addition, Office SharePoint Server 2007 is built directly on top of Windows SharePoint Services 3.0 and everything that is available in ASP.NET 2.0 and Windows SharePoint Services 3.0 is available in Office SharePoint Server 2007. Office SharePoint Server 2007 actually extends and builds on top of Windows SharePoint Services 3.0. When you install Office SharePoint Server 2007, one of the first things the installer does is install Windows SharePoint Services 3.0.
Figure 1. Stacked ASP.NET and SharePoint architecture
One major advantage of this stacked architecture is that you can immediately use the skills that you honed and perfected in one technology in areas that are built on top of that technology. For example, after you get a firm understanding of Features, you can use them in Windows SharePoint Services 3.0 projects and also in Office SharePoint Server 2007 projects.
However, the stacked architecture can challenge some developers, especially those who are new to the SharePoint platform. As developers begin to learn the SharePoint platform, they find that each of the elements in the stacked architecture has its own documentation, support, and peer-to-peer communication resources. Even the available SharePoint resources separate the Windows SharePoint Services 3.0 technology from the Office SharePoint Server 2007 application. The good news, however, is that there are many resources available to you for each of the different technologies in the SharePoint stack. Unfortunately, it can be confusing to know which technology to focus on when researching or troubleshooting a particular problem. In addition, some topics, such as master pages, navigation, and Web services, are addressed in more than one technology.
Using Resources Available for SharePoint Developers
Microsoft provides many ways for developers to get documentation, help, and peer-to-peer support. This section helps to clarify those resources and what they contain.
ASP.NET 2.0 and SharePoint SDKs
The first, and likely most common, resources for all developers are the official SDKs for ASP.NET 2.0, Windows SharePoint Services 3.0, and Office SharePoint Server 2007 on MSDN. Each SDK contains official documentation from the respective product team, and community-contributed content. The community-contributed content is contained in a section at the bottom of all pages in the online SDKs; anyone can sign in and append a comment. With this capability, developers can correct errors they find, clarify points, add code samples, and even provide links to valuable blog posts or forum discussion threads for the specific SDK topic.
Another benefit to the SharePoint SDKs is that the online versions contain excerpts from popular SharePoint books, technical articles, and how-to topics with videos, called visual how-tos. These short screencasts, created by industry-recognized experts, are easy to understand and demonstrate how to perform common SharePoint administration and development tasks. The SharePoint SDKs are also available as downloadable compiled help (.chm) files.
Due to a build process, the download versions of the SharePoint SDKs might trail the online versions on MSDN in providing the latest content. The download versions also do not contain the community-contributed content.
Figure 2. Relationships among the ASP.NET and SharePoint SDKs
The following .NET Framework and SharePoint resources are available to you as you develop on the SharePoint platform:
.NET Framework SDK (.NET Framework Home Page)
Microsoft offers considerable peer-to-peer SharePoint support. Peer-to-peer support can be the most valuable help available to you because it enables you to search previous discussions to answer questions, address challenges, or troubleshoot errors that you are currently experiencing. It is very likely that the particular problem you are experiencing has been experienced by others. It is even more likely that at least one other person experienced it, and that there is a thread that contains information about the resolution.
Microsoft provides two forms of peer-to-peer support: newsgroups and forums. Newsgroups have been around for several years, and anyone can post to them by using various clients. MSDN provides Web-based forums with additional capabilities and functionality that newsgroups do not offer. For example, after signing in, users can quickly see all the posts they have submitted, whether questions have been answered, and which responses answered the questions. Users can also request to be notified via e-mail message when there is activity on a discussion thread that they have selected. As a result of this additional functionality, the MSDN forums are often favored over the newsgroups. While the SharePoint SDKs are separated to specifically address Windows SharePoint Services 3.0 or Office SharePoint Server 2007, the newsgroups and forums are not divided in this way.
The following are newsgroups and forums to investigate for SharePoint development information:
In addition to the various forms of documentation and peer-to-peer support, Microsoft also provides two options for developers to share code and projects:
CodePlex, although very similar to the MSDN Code Gallery, also includes tools for team-based projects. The value that CodePlex adds for collaborative projects includes items such as issue lists, releases, and a Microsoft Visual Studio Team System 2008 Team Foundation Server–based source repository for the project's code.
Finding Documentation and Resources: Best Approach
As discussed earlier, while there are various resources available to SharePoint developers, the stacked architecture of SharePoint Products and Technologies—Office SharePoint Server 2007 built on Windows SharePoint Services 3.0, which is built on the .NET Framework—can make it challenging to know where to find help and documentation for a specific task. The key is learning how to navigate the different technologies in the stack to find the most relevant resource.
For those who are new to SharePoint Products and Technologies, or who have a hard time knowing where to find topics in each of the various resources, the best approach is to use a process of elimination. This can be done in two ways:
By walking the technology stack
By using the namespaces as a guide
Walking the Technology Stack
One option, though inefficient, is to start at either end of the technology stack (.NET Framework or Office SharePoint Server 2007) and try to find the resource you need. If you do not find the topic you want, you go to the next level in the technology stack and look again.
The disadvantages of this approach are that it is inefficient, and some topics are addressed in multiple resources. For example, as discussed later in this article, while master pages are inherently an ASP.NET 2.0 concept, there are nuances about their implementation in Windows SharePoint Services 3.0 sites. Therefore, if you are using the approach of "walking the technology stack" and you stop as soon as you find something that seems like the answer you need, you might miss out on helpful (or possibly critical) information that can be found in other resources. The simple resolution is to research the same topic in all the resources.
Using the Namespaces as a Guide
You can also use the fully qualified name of the object or exception as your guide. This approach is much more efficient and streamlined because it can be broken into two parts:
If the namespace starts with Microsoft.SharePoint.* or Microsoft.Office.Server.*, then it is documented in either the Windows SharePoint Services 3.0 SDK or in the Office SharePoint Server 2007 SDK.
If the namespace starts with anything other than Microsoft.SharePoint.*, specifically if it starts with System.*, you are more likely to find the information you need in the .NET Framework SDK.
You can hone this process even more after you become more familiar with the SharePoint portion of the stack and understand the differences between Windows SharePoint Services 3.0 and Office SharePoint Server 2007. This is addressed later in this article.
Finding the SharePoint Development Topics You Need
The SharePoint product stack—Windows SharePoint Services 3.0 and Office SharePoint Server 2007—includes several products and technologies. Developers who are learning SharePoint Products and Technologies for the first time can quickly get confused about which SDK to focus on. Generally, your best bet is to learn a few namespaces that are always found in the Office SharePoint Server 2007 SDK. Aside from those, nearly everything else is in the Windows SharePoint Services 3.0 SDK. The reason for this is that Office SharePoint Server 2007, while a product that is separate from Windows SharePoint Services 3.0 and that has a separate license for its use, is built on top of Windows SharePoint Services 3.0. (However, Office SharePoint Server 2007 adds several enterprise concepts.)
The real issue is how to distinguish items that are core .NET Framework concepts from SharePoint concepts. The following sections address a few areas and offer some hints for easy identification to help point you in the right direction.
Resources in the Office SharePoint Server 2007 SDK
Office SharePoint Server 2007 is available in a few different versions, such as Microsoft Office SharePoint Server 2007 Standard Edition, Microsoft Office SharePoint Server Enterprise Edition, and Microsoft Office SharePoint Server For Internet Sites. Fortunately for developers, all the versions have a single SDK: the Microsoft Office SharePoint Server 2007 SDK.
As discussed previously, Office SharePoint Server 2007 is built on top of Windows SharePoint Services 3.0. Therefore, all concepts in Windows SharePoint Services 3.0 apply in Office SharePoint Server 2007. In fact, many things that are exclusive to Office SharePoint Server 2007—such as publishing sites, also known as Web content management (WCM) sites—are fundamentally rooted in Windows SharePoint Services 3.0. In a publishing site, all content pages are stored in a special SharePoint list. Developers frequently get confused about how to programmatically access the data in publishing pages. However, the process is nearly identical to modifying or working with Windows SharePoint Services 3.0 lists. The publishing infrastructure creates special objects for stock Windows SharePoint Services concepts such as site collections (Microsoft.SharePoint.Publishing.PublishingSite), sites (Microsoft.SharePoint.Publishing.PublishingWeb), and list items (Microsoft.SharePoint.Publishing.PublishingPage).
Consider the following two code examples. The first obtains the value of a field named "PageByLine" from a Windows SharePoint Services 3.0 list item.
// WSS list SPListItem listItem = SPContext.Current.ListItem; string pageByLine = listItem["PageByLine"].ToString();
The second obtains the same value, if it resides in a publishing site's Pages library.
// Publishing site's Pages library SPListItem listItem = SPContext.Current.ListItem; PublishingPage page = PublishingPage.GetPublishingPage(listItem); string pageByLine = page.ListItem["PageByLine"].ToString();
So what types of information should you look for in the Office SharePoint Server 2007 SDK? The Office SharePoint Server 2007 SDK should be the first stop for information about functionality that is offered through only one of the Office SharePoint Server 2007 editions. For example:
Enterprise Content Management (ECM) (Managing Enterprise Content)
Forms Services (Getting Started with InfoPath Forms Services)
Shared Services Providers
Again, remember that almost everything in this list is founded on a Windows SharePoint Services 3.0 concept, so there might be a bit of an overlap in the two SharePoint SDKs. However, it is best to start with the Office SharePoint Server 2007 SDK.
Another easy identifier that should point you to the Office SharePoint Server 2007 SDK can be found in the namespace of the object or exception that you are researching. The following namespaces are exclusive to Office SharePoint Server 2007:
Resources in the Windows SharePoint Services 3.0 SDK
The Windows SharePoint Services 3.0 SDK is where developers will likely spend most of their research time. As mentioned previously, even if you are primarily focused on technologies that are specific to Office SharePoint Server 2007, you will still spend a considerable amount of time using the Windows SharePoint Services 3.0 SDK. The following is a list of the most common things that you need to be aware of, and will likely investigate, in the Windows SharePoint Services 3.0 SDK:
Field types and field controls (Custom Field Types)
Site columns (Columns)
Content types (Content Types)
Features (Working with Features)
Solutions and Web Part Packages (.wsp files)
Site definitions and site templates (Working with Site Templates and Definitions)
Users, groups, permissions, and security (Security, Users, and Groups)
Content migration (export, import)
Workflow (Workflows in Windows SharePoint Services)
This list addresses the majority of the top items in the SDK. However, it is by no means exhaustive and complete.
In addition, just like the Office SharePoint Server 2007 SDK, the namespace of an object or exception can prove to be the best pointer. However, unlike the Office SharePoint Server 2007 SDK, there is essentially only one namespace in the Windows SharePoint Services 3.0 SDK: Microsoft.SharePoint.*. Part of this namespace is documented in the Office SharePoint Server 2007 SDK list, but when you take a look back at the Office SharePoint Server 2007 SDK, you will notice that only two subsections are exclusive to Office SharePoint Server: Microsoft.SharePoint.Portal and Microsoft.SharePoint.Publishing.
Resources in the ASP.NET 2.0 SDK
As previously mentioned in the stacked architecture discussion, the .NET Framework, or more specifically ASP.NET 2.0, is at the root of all SharePoint sites. However, many concepts can be confusing, because developers expect them to be Windows SharePoint Services 3.0 or Office SharePoint Server 2007 concepts.
Almost all functionality that is available to developers in ASP.NET 2.0 is available throughout SharePoint Products and Technologies, with only a very few exceptions. Some of these exceptions include:
Dropping a user control (*.ASCX) into a Web Part zone and having it be treated as a Web Part at run time. You must host user controls within a Web Part for them to be used as Web Parts in SharePoint Products and Technologies.
Using the OutputCache attribute in the Page or Control directive. The OutputCache directive does not apply because caching is set at a site level, not at a specific page or control level.
Certain very common things are rooted in ASP.NET 2.0 and not in Windows SharePoint Services 3.0. The following list includes a few topics for which you should primarily rely on the .NET Framework SDK for help:
Authentication membership provider model (including the role and profile providers)
HTTP applications, modules, and handlers
Navigation provider model
Windows Workflow Foundation (WF)
Some of the topics in this list, while heavily documented in the .NET Framework SDK, have unique integration points and implementations in SharePoint Products and Technologies. In these cases, you need to check multiple SDKs to determine a complete solution.
Consider the following scenarios:
Authentication. Windows SharePoint Services and Office SharePoint Server fully rely on the .NET Framework for all authentication, resolution of user profiles, and determination of which roles the user is in. The documentation about creating custom authentication providers is found only in the .NET Framework SDK, as is information about implementing them in ASP.NET 2.0 sites. However, there are additional configuration steps that you need to perform to make Windows SharePoint Services or Office SharePoint Server aware of these components.
Master pages. Master pages were introduced in ASP.NET 2.0 and are fully documented in the .NET Framework SDK. However, master pages are used a little differently in SharePoint sites than in typical ASP.NET 2.0 sites. For example, in ASP.NET 2.0 sites, the content pages reference a specific master page that they are linked to. In Windows SharePoint Services or Office SharePoint Server, however, two master pages are set at the site level, and content pages use a token that is interpreted at run time to determine which of the master pages to use. Master pages in Windows SharePoint Services or Office SharePoint Server typically do not reside on the file system; instead, they live in a special library, the Master Page Gallery, in the top-level site of a site collection.
Navigation provider model. Unlike master pages, the navigation provider model does not have much uniqueness to Windows SharePoint Services or Office SharePoint Server. In the area of navigation for SharePoint Products and Technologies, Microsoft provides a slightly modified ASP Menu control and built-in navigation providers that know how to walk the SharePoint object model and site structure to build the navigation structure. However, the topics about creating custom navigation controls, site map data sources, and navigation providers are all found in the .NET Framework SDK.
Web Parts. The Web Part framework was introduced in Windows SharePoint Services 2.0 and Microsoft Office SharePoint Portal Server 2003. The implementation was modified and incorporated into the ASP.NET 2.0 release. In Windows SharePoint Services 3.0, Microsoft retooled their SharePoint infrastructure to completely rely on the ASP.NET 2.0 implementation instead of the earlier Windows SharePoint Services 2.0 implementation. A significant effort was made to ensure Windows SharePoint Services 3.0 would be backward-compatible with Windows SharePoint Services 2.0 Web Parts. Now, the recommendation is to create ASP.NET 2.0 Web Parts for use in SharePoint solutions, instead of creating SharePoint-specific Web Parts. Therefore, all Web Part documentation, including Editor Parts, Web Part connections, and other development topics, can be found in the .NET Framework documentation. Very much like master pages, however, SharePoint Web Parts have a few special nuances. For example, the Web Part definitions are deployed to the Web Part Gallery, a special library that resides in the top-level site of a site collection.
Windows Workflow Foundation (WF). WF was introduced in the .NET Framework 3.0. Almost all development topics related to WF can be found in the .NET Framework SDK. However, while Windows SharePoint Services 3.0 takes great advantage of WF, there are a few things that are unique to Windows SharePoint Services. Specifically Windows SharePoint Services 3.0 adds some SharePoint-specific activities to the WF Base Activity Library. In addition, Windows SharePoint Services binds workflows to items within SharePoint lists and libraries, such as documents. Microsoft has also implemented the necessary pluggable persistence, scheduling, and tracking services into the SharePoint object model and data storage mechanisms (for example, site collections in the content database).
While this article addresses quite a few of the most common areas of SharePoint development and where you can look to get information, it is by no means exhaustive. As with any development effort, it takes experience and time within a product to get a solid feel for where to look for additional information and help. The trick is to understand how the different SharePoint components integrate with each other and with other parts of the .NET Framework. At the same time, developers must distinguish what it is in ASP.NET 2.0 that Windows SharePoint Services or Office SharePoint Server is using and extending to know if they should be looking in the .NET Framework SDK or in one of the two SharePoint SDKs. You also need a solid understanding of what is provided in Windows SharePoint Services 3.0 versus Office SharePoint Server 2007 to know which SharePoint SDK to delve into. Thankfully, there are plenty of hints to follow, especially when it comes to namespaces. Any namespace with System.* in it is typically a .NET Framework item. Any namespace with Microsoft.SharePoint.* in it is usually a Windows SharePoint Services 3.0 item, but could also be an Office SharePoint Server 2007 item. Any namespace with Microsoft.Office.Server.* in it is generally an Office SharePoint Server 2007 item. The only way to get a solid grasp of the different SDKs is to spend time working with the platform in many projects and find the isolation model that works best for you.
For more information, see the following resources: