Chapter 1: SharePoint 2010 Developer Roadmap (Inside SharePoint 2010)

Summary: Learn what's new with the SharePoint developer platform from experts on Microsoft SharePoint Foundation 2010 and Microsoft SharePoint Server 2010. Read a preview of Chapter 1, SharePoint Developer Roadmap, from Inside Microsoft SharePoint 2010.

Applies to: Business Connectivity Services | SharePoint Foundation 2010 | SharePoint Server 2010 | Visual Studio

This article is a preview excerpt from Inside Microsoft SharePoint 2010 by Ted Pattison, Andrew Connell, and Scot Hillier (ISBN 9780735627468, published with the authorization of Microsoft Corporation by O'Reilly Media, Inc. Copyright © 2010 by Critical Path Training, LLC). No part of these chapters may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, electrostatic, mechanical, photocopying, recording, or otherwise—without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.

Contents

• Introduction

• SharePoint Foundation

• SharePoint Server 2010

• Windows PowerShell Boot Camp for SharePoint Professionals

• Conclusion

• Additional Resources

• About the Authors

Introduction

Unless you've been hiding under a rock or programming in the clouds, you've probably noticed that Microsoft SharePoint technologies have become popular. Over the last few years, IT professionals throughout the industry—including many people at Microsoft—have been surprised by the accelerated adoption rate of SharePoint and its impressive sales revenue, which is over a billion dollars.

It is safe to say that SharePoint technologies have made it into the mainstream of software products used by companies and organizations around the world. Today, millions of people work with SharePoint technologies every day, including business users, power users, executives, site administrators, farm administrators, and professional developers.

Microsoft has released four versions of SharePoint technologies, which are listed in Table 1-1. Each SharePoint release has included an underlying core infrastructure product and a second product that adds business value to the infrastructure. The core infrastructure product has always been free to customers who already have licenses for the underlying server-side operating system, Microsoft Windows Server. Microsoft makes money on SharePoint technologies by selling customers server-side licenses as well as client access licenses (CALs).

Table 1-1 A Brief History of SharePoint

Year	Core Infrastructure Product	Business Value Product
2001	SharePoint Team Services	SharePoint Portal Server 2001
2003	Windows SharePoint Services 2.0	Microsoft SharePoint Portal Server 2003
2007	Windows SharePoint Services 3.0	Microsoft Office SharePoint Server 2007
2010	Microsoft SharePoint Foundation	Microsoft SharePoint Server 2010

SharePoint 2001 introduced an environment that allowed users to create sites, lists, and document libraries on demand based on a data-driven design. The implementation was based on a Microsoft SQL Server database that tracked the creation of sites and lists by adding records to a static set of database tables. This initial version of SharePoint had a couple noteworthy shortcomings. First, it was cumbersome to customize sites. Second, the files uploaded to a document library were stored on the local file system of the front-end Web server, which made it impossible to scale out SharePoint Team Services sites using a farm of front-end Web servers.

SharePoint 2003 was the first version to be implemented on top of the Microsoft .NET Framework and ASP.NET. This version began to open new opportunities for professional developers looking to extend the SharePoint environment with Web Parts and event handlers. Also in this version, Microsoft altered the implementation for document libraries to store files inside a back-end SQL Server database, which made it possible to scale out SharePoint sites using a standard farm of front-end Web servers.

SharePoint 2007 introduced many new concepts to the underlying SharePoint architecture, including site columns, content types, and features and solution packages. Microsoft also improved the integration of SharePoint with ASP.NET, which made it possible for .NET developers to extend SharePoint sites by creating familiar ASP.NET components such as master pages, user controls, navigation providers, authentication providers, and custom HttpModule components.

SharePoint 2010 is the fourth and most recent release of SharePoint technologies. It includes Microsoft SharePoint Foundation and Microsoft SharePoint Server 2010. The goal of this chapter is to build your high-level understanding of SharePoint Foundation from the viewpoint of a professional developer. Along the way, you will learn how SharePoint Server 2010 extends SharePoint Foundation to add extra functionality and business value.

SharePoint Foundation

SharePoint Foundation introduces many changes to the core platform from SharePoint 2007. The improved user experience in the browser constitutes the most obvious change for experienced SharePoint users moving to SharePoint 2010. The SharePoint 2007 user interface experience is outdated. It wasn't designed to today's HTML standards, nor does it embrace any of the principles of Web 2.0. These limitations negatively impact accessibility and cross-browser functionality. The user experience of SharePoint 2007 can also be criticized for triggering unnecessary server-side postbacks and confusing page transitions.

SharePoint 2010 introduces a new AJAX-powered user interface that significantly improves the user experience. The pages in a SharePoint 2010 site eliminate unnecessary postbacks by communicating with the Web server using asynchronous JavaScript calls. SharePoint Foundation also eliminates potentially confusing page transitions using inline editing and modal dialogs. Finally, SharePoint Foundation enhances the user experience by introducing the server-side Ribbon, which allows the user to locate and execute a larger number of contextual commands without having to navigate away from the current page.

SharePoint Foundation includes a wealth of enhancements beyond user interface changes. Table 1-2 lists some of the new enhancements that will be most interesting to developers moving from SharePoint 2007. These topics are covered throughout the course of this book.

Table 1-2 Enhancements for Developers in SharePoint Foundation

Enhancement	Benefit
Service application architecture	Redesigned infrastructure to facilitate sharing of resources across Web applications and farms.
Windows PowerShell support	New support and capabilities for writing administrative scripts.
Feature versioning and upgrade	New support for versioning and upgrading features.
SharePoint Developer Tools for Visual Studio 2010	A first-class development experience for SharePoint developers (finally).
Sandboxed solutions	New support for deploying solution packages at site collection scope in a sandboxed environment.
New features for throttling lists and controlling query execution	Enhanced support for stabilizing the farm by prohibiting large, inefficient queries.
New events for sites, lists, and workflows	Additional events for developers to hook up event handlers.
LINQ to SharePoint provider	New support for writing LINQ query statements to access SharePoint list data.
REST-based access to SharePoint list items	New support for accessing SharePoint list data from across the network using REST-based Web service calls.
Client-side object model	Ability to leverage the SharePoint object model from across the network when programming with .NET, Silverlight, and JavaScript.
Enhanced support for integrating Silverlight applications	Rich support for deploying and versioning Silverlight applications within a SharePoint environment.
Claims-based security	New authentication support for leveraging external identity management systems and extending access control in SharePoint sites using custom claims.
Business Connectivity Services (BCS) and external lists	New support for creating read-write connections to back-end databases and line-of-business systems and exposing the data as lists within SharePoint sites.
.NET Assembly Connectors for BCS	Support for creating a custom component to integrate any data source with the BCS.

SharePoint Foundation Architecture

At its core, SharePoint Foundation is a provisioning engine—that is, its fundamental design is based on the idea of using Web-based templates to create sites, lists, and libraries to store and organize content. Templates are used to create both new Web sites and various elements inside a Web site, such as lists, pages, and Web Parts.

SharePoint Foundation is particularly helpful to companies and organizations faced with the task of creating and administering a large number of Web sites because it dramatically reduces the amount of work required. Someone in the IT department or even an ordinary business user can provision (a fancy word for create) a site in SharePoint Foundation in less than a minute by filling in a browser-based form and clicking the OK button. Creating a new page or a new list inside a site is just as easy.

SharePoint Foundation takes care of all the provisioning details behind the scenes by adding and modifying records in a SQL Server database. The database administrator doesn't need to create a new database or any new tables. The ASP.NET developer doesn't need to create a new ASP.NET Web site to supply a user interface. And the system administrator doesn't need to copy any files on the front-end Web server or configure any Internet Information Services (IIS) settings. It all just works. That's the magic of SharePoint.

The architecture of SharePoint Foundation was specifically designed to operate in a Web farm environment. Figure 1-1 shows a basic diagram of a simple Web farm with two frontend Web servers and a database server. In scenarios that have multiple front-end Web servers, a network load balancer is used to take incoming HTTP requests and to determine which front-end Web server each request should be sent to.

Figure 1-1 SharePoint Foundation is designed to scale out using a farm of front-end Web servers.

SharePoint Foundation and SharePoint Server 2010 are available only in 64-bit versions. They can be installed on a 64-bit version of Windows Server 2008 or Windows Server 2008 R2. When building a development environment, you also have the option of installing either SharePoint Foundation or SharePoint Server 2010 on a 64-bit version of a client operating system such as Windows 7 or Windows Vista.

SharePoint Foundation leverages IIS 7.0 on front-end Web servers to listen for incoming HTTP requests and to manage the server-side worker processes using the IIS application pool infrastructure. The runtime environment of SharePoint Foundation runs within a worker process launched from the IIS application pool executable, named w3wp.exe, as shown in Figure 1-2. You can see in Figure 1-2 that SharePoint Foundation is built on .NET Framework 3.5 and ASP.NET 3.5 with Service Pack 1.

Figure 1-2 The SharePoint Foundation runtime loads into an IIS application pool running ASP.NET 3.5.

Recall that SharePoint 2007 was built on top of .NET 3.0. Although configuring front-end Web servers running SharePoint 2007 to support .NET 3.5 is possible, this task proved to be challenging for a number of reasons. Consequently, a large percentage of SharePoint 2007 development hasn't taken advantage of the programming techniques introduced in .NET 3.5. One nice aspect of moving to SharePoint 2010 is that this new version provides out-of-the-box support for valuable .NET 3.5 features such as AJAX, LINQ, and Silverlight. This book assumes that a healthy percentage of developers moving from SharePoint 2007 to SharePoint 2010 will be using these .NET 3.5 features for the first time.

You should also note that the initial release of SharePoint 2010 won't provide support for .NET 4.0. At the time of this writing, Microsoft has not yet made any announcements about when .NET 4.0 support will be integrated into either SharePoint Foundation or SharePoint Server 2010.

SharePoint Farms

Every deployment of SharePoint Foundation is based on the concept of a farm. Simply stated, a SharePoint farm is a set of one or more server computers working together to provide SharePoint Foundation functionality to clients. For simple scenarios, you can stand up a SharePoint 2010 farm by installing and configuring everything you need on a single server computer. A SharePoint farm in a typical production environment runs SQL Server on a separate dedicated database server and can have multiple front-end Web servers, as shown in Figure 1-3. As you will see later in this chapter, a farm can also run one or more application servers in addition to a database server and a set of Web servers.

Figure 1-3 You can create a SharePoint development environment using a single server farm.

Each SharePoint farm runs a single SQL Server database known as the configuration database. SharePoint Foundation creates a configuration database whenever it creates a new farm in order to track important farm-wide information. For example, the configuration database tracks which front-end Web servers are associated with the farm as well as which users have been assigned administrative permissions within SharePoint Foundation at the farm level.

When creating a SharePoint development environment, it is best to install and configure SharePoint 2010 as a single-server farm. Remember that you have the option of installing SharePoint Foundation or SharePoint Server 2010 on a client operating system such as a 64-bit version of Windows 7. Building out your development environment using a 64-bit version of Windows 7 as the underlying operating system is the best approach if you must base your development environment on a client-side operating system.

If possible in your work environment, you should consider installing SharePoint Foundation or SharePoint Server 2010 on a 64-bit version of Windows Server 2008 or Windows Server 2008 R2. One option is to install a version of SharePoint 2010 on a native installation of Windows Server. Another popular option is to install a version of SharePoint 2010 on a virtual machine (VM). For example, you can install a 64-bit version of Windows Server 2008 R2 and configure Hyper-V. Hyper-V allows you to create a VM on which you can install a 64-bit version of Windows Server 2008 R2 and SharePoint Server 2010.

A key advantage of building a SharePoint development environment on a server-side operating system such as Windows Server 2008 R2 is that you can configure Active Directory Domain Services to provide a more realistic simulation of the networked environment that will be running in production. Figure 1-3 shows the layers of software we recommend that you install on a developer workstation you're configuring for SharePoint 2010 development.

As a SharePoint developer, you must remember that farms come in all different shapes and sizes. Although you will likely write and test your code on a single-server farm, that is probably not the type of farm in which your code will be deployed. It can be a big mistake to assume that your target SharePoint production environment is just like your development environment.

Many companies that are invested in SharePoint development categorize their farms into three different types. SharePoint developers write and debug SharePoint solutions in development farms. Staging farms simulate a more realistic environment and are used to conduct quality assurance testing on SharePoint solutions. For example, the servers in a staging farm should be built without installing developer tools such as Microsoft Visual Studio 2010. Once a SharePoint solution has been thoroughly tested in a staging farm, it can be deployed in a production farm, where its functionality is made available to users.

SharePoint 2010 Central Administration

As a SharePoint developer, you must wear many hats. One hat you frequently wear is that of a SharePoint farm administrator. You should become familiar with the administrative site that SharePoint Foundation automatically creates for each farm. This administrative site is known as SharePoint 2010 Central Administration, and its home page is shown in Figure 1-4.

Figure 1-4 SharePoint developers should become familiar with SharePoint 2010 Central Administration.

Notice that Figure 1-4 shows the home page of SharePoint 2010 Central Administration in a farm with only SharePoint Foundation installed. If SharePoint Server 2010 is also installed, you'll see additional links to administrative pages that are not installed by SharePoint Foundation. Also note that SharePoint 2010 Central Administration is extensible. If you need to create a SharePoint solution for administrative purposes, you can integrate your work into SharePoint 2010 Central Administration by adding custom links and custom administration pages.

Scenario: Introducing Wingtip Toys

Many of the example configurations and code samples in this book are based on Wingtip Toys, a company that was fictitiously founded in 1882 by Henry Livingston Wingtip. Wingtip Toys has a long and proud history of producing the industry's most unique and inventive toys for people of all ages. Wingtip Toys has set up an intranet using SharePoint internally to provide a means of collaboration between its trinket design scientists, its manufacturing team, and its remote sales force. It has also erected an extranet using SharePoint to interact with partners and toy stores around the world. Finally, Wingtip Toys has decided to use SharePoint to create its Internet-facing site to advertise and promote its famous line of toys and novelties.

Web Applications

SharePoint Foundation is built on top of IIS 7.0 and relies on IIS Web sites to handle incoming HTTP requests. Therefore, you need to understand exactly what an IIS Web site really is.

An IIS Web site provides an entry point into the IIS Web server infrastructure. For example, the default Web site IIS creates automatically listens for incoming HTTP requests on port 80. You can create additional IIS Web sites to provide additional HTTP entry points using different port numbers, different IP addresses, or different host headers. In our scenario, we'll use host headers to create HTTP entry points for domain names such as http://intranet.wingtip.com.

SharePoint Foundation creates an abstraction on top of IIS that is known as a Web application. At a physical level, a Web application is a collection of one or more IIS Web sites configured to map incoming HTTP requests to a set of SharePoint sites. The Web application also maps each SharePoint site to one or more specific content databases. SharePoint Foundation uses content databases to store site content such as list items, documents, and customization information.

Warning

Don't Touch the SharePoint Databases.

When developing for SharePoint Foundation, you're not permitted to directly access the configuration database or any of the content databases. For example, you must resist any temptation to write ADO.NET code that reads or writes data from the tables inside these databases. Instead, you should write code against the SharePoint Foundation programming APIs to reach the same goal, and leave it to SharePoint Foundation to access the configuration database and content database behind the scenes.

SharePoint Foundation uses ASP.NET 3.5 to extend the standard behavior of an IIS Web site. It does this by configuring IIS Web sites to run SharePoint-specific components in the ASP.NET pipeline, including a custom HttpModule and a custom HttpHandler. This integration with ASP.NET allows SharePoint Foundation to take control over every request that reaches an IIS Web site that has been configured as a SharePoint Web application.

Keep in mind that every SharePoint Web application runs as one large ASP.NET application. Consequently, SharePoint Foundation adds a standard ASP.NET web.config file to the root directory of each IIS Web site associated with a Web application. This high-level design can be counterintuitive for developers migrating to SharePoint Foundation from ASP.NET. A single SharePoint site is unlike an ASP.NET site because it can't have its own web.config file. That means a single web.config in SharePoint Foundation supplies configuration information for every site in a Web application. This is true even in scenarios where the number of sites in a Web application reaches into the hundreds or thousands.

A SharePoint farm typically runs two or more Web applications. The first Web application is created automatically and is used to run SharePoint 2010 Central Administration. You need at least one more Web application to create the sites that are used by typical users. The IT staff at Wingtip Toys decided to configure their production farm with three different Web applications used to reach employees, partners, and customers, as shown in Figure 1-5.

Figure 1-5 Each Web application has one or more content database.

A key thing to remember about Web applications is that each one has its own independent security and authentication settings. This creates a valuable degree of flexibility because different sites in the same farm can be configured for access by different types of users.

The Wingtip IT staff configured the first Web application for intranet usage by requiring Integrated Windows authentication and by prohibiting anonymous access. They configured the second Web application for extranet usage by authenticating external users with a custom ASP.NET authentication provider. They configured the third Web application to allow anonymous access so that any user on the Internet could potentially access their public Web site anonymously.

The introduction of claims-based security support into SharePoint 2010 provides developers with new possibilities for configuring a Web application. One such possibility is the ability to outsource identity management to an identity service publicly available on the Internet, such as Windows Live ID. This approach gives developers the ability to track users for the purposes of security, auditing, and personalization but without the hassles of setting up a user database, storing credentials, and dealing with all the associated password management headaches.

The Wingtip IT staff configured the Web application for their public Web site to allow anonymous access but also to make logging into the site an available option. They configured a trust within the farm to the Windows Live ID service and then configured the Web application to use Windows Live ID as its identity provider. When customers attempt to log into the Wingtip public Web site, they are redirected to the Windows Live ID site and prompted to enter their Windows Live ID credentials. Once authenticated by Windows Live ID, the customer is then redirected back to the Wingtip public Web site with an established identity.

Service Applications

A SharePoint farm is often scaled by efficiently sharing resources across sites running in different Web applications and by offloading processing cycles from front-end Web servers to dedicated application servers. SharePoint 2007 provides a resource-sharing architecture based on Shared Service Providers (SSPs). However, SSPs are not ideal because they have no support in the core platform. They are part of the SharePoint Server 2007 product, and they don't support extensibility.

SharePoint Foundation introduces a new infrastructure for service applications that replaces the SSP architecture from SharePoint Server 2007. In SharePoint 2010, service applications are used to facilitate sharing resources across sites running in different Web applications and different farms. The new service application architecture also provides the means for scaling a SharePoint farm by offloading processing cycles from the front-end Web servers over to dedicated application servers.

A key benefit of this new architecture is that you can treat a service application as a pluggable component. Once you install and create a service application, you can configure it for several different deployment scenarios. In simple farms, an instance of the service application can run on each front-end Web server. In more complex farms, such as the one shown in Figure 1-6, a service application can be configured to run on a separate application server or in a farm of application servers.

Figure 1-6 SharePoint farms run service applications in addition to Web applications.

A service application targeting SharePoint 2010 must be written to a specific set of requirements. For example, a service application must query the configuration database about its current deployment configuration and adjust its behavior accordingly.

When a service application runs across the network on a dedicated application server, it relies on a proxy component on the front-end Web server. The proxy component is deployed along with the service application and provides value by abstracting away the code required to discover where the service application lives on the network. The service application proxy component provides additional value by encapsulating the Windows Communication Foundation (WCF) code used to execute Web service calls on the target service application.

The proxy-based design of service applications provides flexibility in terms of deployment and configuration. For example, you can configure a proxy in one farm to communicate with a service application in another farm. The proxy simply consults the configuration database and discovers the correct address for the application server running the service application. The implication here is that the new service application architecture makes it much easier to share resources across farms while still controlling what services are made available and how they are consumed.

Four built-in service applications ship with SharePoint Foundation, as shown in Figure 1-7.When a new farm is created, SharePoint Foundation automatically creates and configures two important service applications: Application Discovery and Load Balancer Service Application and Security Token Service Application. The other two service applications built into SharePoint Foundation are Business Data Connectivity Service and Usage and Health data collection, which you can create manually or by running the Farm Configuration Wizard available in the SharePoint 2010 Central Administration site.

Figure 1-7 SharePoint Foundation includes four standard service applications.

Unlike the SSPs in SharePoint 2007, service applications were designed with developer extensibility in mind. Any SharePoint developer with the proper knowledge and incentive can create a service application that can plug into any SharePoint 2010 farm.

Even if you never find a good reason to create your own service application, you need to understand how service applications work and how they fit into the high-level architecture of SharePoint Foundation. For example, SharePoint Server 2010 delivers a good deal of its functionality through service applications. Furthermore, many other groups within the Office team at Microsoft have built their own service applications that can be installed and configured in a SharePoint 2010 farm.

SharePoint Server 2010

SharePoint Server 2010 is really just a piece of software that's been written to run on SharePoint Foundation. Every installation of SharePoint Server 2010 begins with an installation of SharePoint Foundation. After installing SharePoint Foundation, the installation for SharePoint Server 2010 then installs its own templates, components, and service applications.

Microsoft sells different editions of SharePoint Server 2010 using several different SKUs. SharePoint Server 2010 Standard Edition supplies core functionality such as enterprise search, content publishing, user profiles, and my sites. SharePoint Server 2010 Enterprise Edition extends the standard edition by adding extra functionality for security, business intelligence, managed metadata, and rich integration with Microsoft Office client applications.

To help you understand some of the additional functionality SharePoint Server 2010 layers on top of SharePoint Foundation, Table 1-3 lists the service applications that SharePoint Server 2010 installs as well as the edition of SharePoint Server 2010 required to use each service application.

Table 1-3 SharePoint Server 2010 Service Applications

Service Application	Edition
Access Services	Enterprise
Application Registry Services	Standard
Excel Services	Enterprise
Managed Metadata Service	Standard
PerformancePoint Services	Enterprise
Search Service	Standard
Secure Store	Standard
State Service	Standard
User Profile Service	Standard
Visio Graphics Service	Enterprise
Web Analytics Service	Enterprise
Word Automation Services	Standard

Sites

Now that you understand the high-level architecture of a SharePoint farm, you need to know how SharePoint Foundation creates and manages sites within the scope of a Web application. Let's start by asking a basic question: What exactly is a SharePoint site?

This question has many possible answers. For example, a site is an endpoint that is accessible from across a network such the Internet, an intranet, or an extranet. A site is also a storage container that allows users to store and manage content such as list items and documents. In addition, a site is a customizable entity that allows privileged users to add pages, lists, and child sites. Finally, a site is a securable entity whose content is accessible to a configurable set of users.

As a developer, you can also think of a site as an instance of an application. For example, the scientists at Wingtip Toys use a SharePoint site to automate the business process of approving a new toy idea. When Wingtip scientists have new ideas for a toy, they describe their ideas in Microsoft Word documents, which they then upload to a document library in the site. The approval process is initiated whenever a scientist starts a custom approval workflow on one of those documents.

A site can also be used as an integration point to connect users to back-end data sources such as a database application or a line-of-business application such as SAP or PeopleSoft. The Business Connectivity Services that ship with SharePoint Foundation make it possible to establish a read-write connection with a back-end data source. One valuable aspect of the Business Connectivity Services architecture is that this external data often appears to be a native SharePoint list. There are many user scenarios and developer scenarios in which you can treat external data just as you would treat a native SharePoint list.

Site Collections

Every SharePoint site must be provisioned within the scope of an existing Web application. However, a site can't exist as an independent entity within a Web application. Instead, every site must also be created inside the scope of a site collection.

A site collection is a container of sites. Every site collection has a top-level site. In addition to the top-level site, a site collection can optionally contain a hierarchy of child sites. Figure 1-8 shows a Web application with three site collections. The first site collection contains just a top-level site. The second contains one level of child sites below the top-level site. The third contains a more complex hierarchy with three levels.

Figure 1-8 Each site collection has a top-level site and can optionally contain a hierarchy of child sites.

When a company first begins using SharePoint Foundation or SharePoint Server 2010, one of the first questions that comes up is how to partition sites across site collections. For example, should you create one big site collection with lots of child sites, or should you create many individual site collections? This decision is usually best made after thinking through all the relevant issues discussed in the next few paragraphs. You must gain an understanding of how partitioning sites into site collections affects the scope of administrative privileges, security boundaries, backup and restore operations, and site design.

You could be asking yourself why the SharePoint Foundation architecture requires this special container to hold its sites. For starters, site collections represent a scope for administrative privileges. If you've been assigned as a site collection administrator, you have full administrative permissions within any existing site and any future site created inside that site collection.

Think about the requirements of site management in a large corporation that's provisioning thousands of sites per year. The administrative burden posed by all these sites is going to be more than most IT staffs can deal with in a timely manner. The concept of the site collection is important because it allows the IT staff to hand off the administrative burden to someone in a business division who takes on the role as the site collection owner.

Let's walk through an example. The Wingtip Toys IT staff is responsible for provisioning new site collections, and one of the Wingtip business divisions submits a request for a new site. Imagine the case where the Wingtip Sales Director has put in a request to create a new Team site for his sales staff. A Wingtip IT staff member would handle this request by creating a new site collection with a Team site as its top-level site.

When creating the new site collection, the Wingtip IT staff member would add the Wingtip Sales Director who requested the site as the site collection owner. The Wingtip Sales Director would have full administrative privileges inside the site collection and could add new users, lists, and pages without any further assistance from the Wingtip IT staff. The Wingtip Sales Director could also add child sites and configure access rights to them independently of the top-level site.

A second advantage of site collections is that they provide a scope for membership and the configuration of access rights. By design, every site collection is independent of any other site collection with respect to what security groups are defined, which users have been added as members, and which users are authorized to perform what actions.

For example, imagine that the Wingtip IT staff has provisioned one site collection for the Sales department and a second site collection for the Accounting department. Even though some users within the Accounting department have administrative permissions within their own site collection, there's nothing they can do that will affect the security configuration of the Sales site collection. SharePoint Foundation sees each site collection as an island with respect to security configuration.

A third reason for site collections is that they provide a convenient scope for backup and restore operations. You can back up a site collection and later restore it with full fidelity. The restoration of a site collection can take place in the same location where backup was made. Alternatively, a site collection can be restored in a different location—even inside a different farm. This technique for backing up a site collection and restoring it in another location provides one possible strategy for moving sites and all the content inside from one farm to another.

A final motivation for you to start thinking about in terms of site collections is that they provide a scope for many types of site elements and for running custom queries. For example, the server-side object model of SharePoint Foundation provides you with the capability to run queries that span all the lists within a site collection. However, there is no query mechanism in the SharePoint server-side object model that spans across site collections. Therefore, if your application design calls for running queries to aggregate list data from several different sites, it makes sense to add sites to the same site collection when they contain lists that must be queried together.

Imagine a case in which the West Division of the Wingtip Sales team has four field offices. The Wingtip Sales Director could create a child site for each field office below a site that was created for the West Division. Now assume that each child site has a Contacts list that is used to track sales leads. By using programming techniques shown later in this book, you can execute queries at the scope of the West Division site that would aggregate all the Contacts items found across all of its child sites. You could execute the same query at a higher scope and get different results. For example, if you executed the same query scoped to the top-level site, it would aggregate all the Contacts found throughout the site collection, including both the West Division and the East Division.

Customizing Sites

SharePoint Foundation provides many user options for configuring and customizing sites. If you're logged into a site as the site collection owner or as a site administrator, you can perform any site customization options supported by SharePoint Foundation. If you're logged into a site without administrative privileges in the role of a contributor, however, you won't have the proper permissions to customize the site. Furthermore, if you're logged in as a contributor, SharePoint Foundation uses security trimming to remove the links and menucommands that lead to pages with functionality for which you don't have permissions.

If you're logged into a standard Team site as a site administrator, you should be able to locate and drop down the Site Actions menu in the top-left corner of the page. This menu provides commands that allow you to edit the current page; to create new pages, lists, and child sites; to configure security; and to navigate to the Site Settings page shown in Figure 1-9.

Figure 1-9 The Sites Setting page is accessible to site administrators in any site.

The Site Settings page provides links to pages that allow you to perform various administrative and customization tasks. Notice that the Site Settings page for a top-level site contains one section for Site Administration and a second section for Site Collection Administration. The Site Settings page for child sites doesn't include the section for Site Collection Administration.

You can see in Figure 1-9 that there are several sections of links, including Users and Permissions, Look and Feel, Galleries, and Site Actions, which provide links to various other administrative pages for the current site. If you're new to SharePoint Foundation, you should take some time to explore all the administrative pages accessible through the Site Settings page. Also keep in mind that Figure 1-9 shows only the links on the Site Settings page of a Team site running within a SharePoint Foundation farm. If the site were running in a SharePoint Server 2010 farm, there would be additional links to even more site administration pages that are not part of the standard SharePoint Foundation installation.

Creating and Customizing Pages

The support for wiki page libraries and Web Parts is an enabling aspect of SharePoint Foundation. Business users with no experience in Web design or HTML can quickly add and customize Web pages.

Although SharePoint 2007 supports wiki page libraries, this support has been significantly enhanced in SharePoint Foundation. An example of the increased support is evident when you create a standard Team site. As part of the provisioning process, SharePoint Foundation automatically creates a new wiki library at the path of SitePages off the root of the site, and it adds a wiki page named Home.aspx. It additionally configures Home.aspx to be the home page of the site, so it becomes the first page users see when navigating to the site.

Customizing the home page is simple for any user who has the proper permissions. The user can enter edit mode using either the Site Actions menu or the Ribbon. Once in edit mode, the user is free to simply type text or copy and paste from another application. The Insert tab in the Ribbon also makes it easy for the user to add tables, links, and images.

Web Part technology also plays a prominent role in page customization. Web Parts are based on the idea that developers supply a set of visual components that users can add and move around in their pages. Every site collection has a Web Part Gallery, which contains a set of Web Part template files. This set of Web Part template files determines which types of Web Parts can be added to pages within the site collection.

Although earlier versions of SharePoint technologies supported Web Parts, they were not as flexible as SharePoint Foundation because Web Parts could be added only to Web Part pages. SharePoint Foundation now makes it possible to add Web Parts anywhere inside a wiki page. When you're editing the content of a wiki page, you can place the cursor wherever you'd like and add a new Web Part using the Insert tab in the Ribbon. The new Web Part appears inline along with your other wiki content. This inline Web Part capability, combined with the wiki editing experience, can go a long way toward making SharePoint sites look less boxy—a common complaint about previous versions.

Creating and Customizing Lists

The Site Actions menu provides several different commands for creating new pages and new lists, such as New Page, New Document Library, and New Site. If you click the More Options command in the Site Actions menu, SharePoint Foundation displays the Create dialog shown in Figure 1-10. The SharePoint Foundation Create dialog provides a user interface built using Silverlight, which allows a user to filter through the available templates for creating pages, lists, and child sites. Figure 1-10 shows a filtered view of the templates available for creating tracking lists in the Create dialog.

Figure 1-10 The SharePoint Foundation Create dialog is implemented using a Silverlight application.

In addition to list templates, the standard collaboration features of SharePoint Foundation also include templates for creating several different types of document libraries. Besides the standard document library type, there are also more specialized document library types for wiki page libraries, picture libraries, and InfoPath form libraries.

What's appealing to SharePoint users is that once they create a new list, it's immediately ready to use. SharePoint Foundation provides instant gratification by including page templates as part of the list template itself, making it possible to create each new list and document library with a set of pages that allow users to add, view, modify, and delete items and documents.

Once a list has been created, SharePoint Foundation gives a user the flexibility to further customize it. SharePoint Foundation provides a List Settings page for each list and document library. Figure 1-11 shows a typical List Settings page. It provides a set of links to secondary pages that allow the user to modify properties of a list such as its title and description and to configure other important aspects of the list, including versioning, workflow, and security permissions. The List Settings page also provides links to add and manage the set of columns behind the list.

Figure 1-11 The List Settings page allows you to modify list properties and to add columns.

SharePoint Foundation provides many built-in list templates to track information about common business items such as tasks, contacts, and scheduled events. For business scenarios in which the list data that needs to be tracked doesn't conform to a built-in list template, SharePoint Foundation makes it easy for a user to create a custom list with a unique set of columns for these ad hoc situations.

SharePoint Foundation provides a list template named Custom List. When you create a new list from this template, it will initially contain a single column named Title. A user can add columns with just a few mouse clicks. Each added column is based on an underlying field type.

SharePoint Foundation supplies a rich set of built-in field types for columns whose values are based on text, numbers, currency, dates, and yes/no values. In Chapter 7, you'll see that you can also extend SharePoint Foundation by developing a custom field type for scenarios in which you need to store column values in the content database that need custom validation logic or specialized rendering instructions.

SharePoint Designer 2010

Microsoft SharePoint Designer 2010 is a specialized site customization tool. It is a rich desktop application that often makes customizing a site easier than when done through the browser. Not only is SharePoint Designer 2010 free, but the product is also significantly different from and better than SharePoint Designer 2007.

Figure 1-12 shows the redesigned user interface of SharePoint Designer 2010. Significant changes were made to simplify the user's view of a SharePoint site. Gone are the sites that show just a hierarchy of folders and files. The new user interface structures the elements of a site into logical collections of site objects such as Lists and Libraries, Workflows, Master Pages, and Subsites. A site object named All Files shows the old view of folders and files that will be familiar to users moving from SharePoint Designer 2007.

Figure 1-12 SharePoint Designer 2010 is a specialized tool for site customization.

SharePoint Designer 2010 is primarily designed to assist users in the role of site collection owner or site administrator. The tool makes it quick and easy to examine the properties and structure of a site and to perform common site tasks such as adding security groups and configuring permissions. Many users will also prefer the experience of SharePoint Designer 2010 over the browser when it comes to creating new lists and adding columns.

SharePoint Designer 2010 also allows a user to perform site customizations that aren't possible through the browser. The capability to create and customize workflows using a new set of workflow designers provides a great example. Using SharePoint Designer 2010, an experienced user can create and design complex workflows on targets such as sites, lists, and document libraries. SharePoint Designer 2007 had severe problems with creating reusable workflows. Fortunately, SharePoint Designer 2010 has overcome these problems.

Workflows created with SharePoint Designer 2010 can be reused across lists within the same site collection. These workflows can also be exported and reused across site collections, Web applications, and farms. As you'll see in Chapter 11, you can export a workflow created with SharePoint Designer 2010 and then import it into Visual Studio 2010.

Site Customization vs. SharePoint Development

In one sense, SharePoint Foundation lessens the need for professional software developers because it empowers users to create and customize their own sites. In minutes, a user can create a SharePoint site, add several lists and document libraries, and customize the site's appearance to meet the needs of a particular business situation. An identical solution that has all the rich functionality that SharePoint Foundation provides out of the box would typically take an ASP.NET development team weeks or months to complete.

In another sense, SharePoint Foundation provides professional developers with new and exciting development opportunities. As with any other framework, the out-of-the-box experience with SharePoint Foundation takes you only so far. At some point, you'll find yourself needing to create custom list types and write code for custom SharePoint components such as Web Parts, event handlers, and workflows. What is attractive about SharePoint Foundation as a development platform is that it was designed from the ground up with developer extensibility in mind.

As you begin to design software for SharePoint 2010, it is critical that you differentiate between customization and development. SharePoint Foundation is very flexible for users because it was designed to support high levels of customization. As we've pointed out, you no longer need to be a developer to build a complex and highly functional Web site. Today, many sophisticated users are capable of customizing SharePoint sites for a large number of business scenarios. Site customization has its limitations, however. SharePoint Foundation records every site customization by modifying data within a content database, whether a new list is created or an existing list is customized with new columns and views. All types of site customization that can be performed using SharePoint Designer 2010 are recorded this way.

The fact that all site customization is recorded as a modification to the content database is both a strength and a weakness for SharePoint Foundation. It is a strength because it provides so much flexibility to users and site administrators doing ad hoc customizations. It is a weakness from the perspective of a professional software developer because customization changes are hard to version and can also be hard or impossible to make repeatable across site collections and farms.

Think about a standard ASP.NET development project in which all the source files you're working with live within a single directory on your development machine. Once you've finished the site's initial design and implementation, you can add all the site's source files to a source control management system such as Team Foundation Server.

By using a source control management system, you can formalize a disciplined approach to deploying and updating an ASP.NET site after it has gone into production. You can also elect to push changes out to a staging environment where your site's pages and code can be thoroughly tested before they are used in the production environment.

As a developer, you should ask yourself the following questions: How do I conduct source control management of customization changes? How do I make a customization change to a list definition or a page instance and then move this change from a development environment to a staging environment and finally to a production environment? How do I make a customization change within a site and then reuse it across a hundred different sites? Unfortunately, these questions have tough answers, and usually you'll find that a possible solution isn't worth the trouble.

Fortunately, as a developer you can work at a level underneath the SharePoint Foundation customization infrastructure. To be more specific, you can work with the low-level source files to create underlying templates for items such as pages and lists. These low-level source files don't live inside the content database; instead, they live within the file system of the frontend Web server.

Working at this level is complex and has a steep learning curve. Even so, this low-level approach lets you centralize source code management and have a more disciplined approach to code sign-off when moving functionality from development to staging to production. This approach also makes versioning and reuse of code far more manageable across multiple sites, Web applications, and farms.

For the remainder of this book, we differentiate between customization and development according to these criteria. SharePoint site customizations are updates to a site accomplished by making changes to the content database, generally through the Web browser or SharePoint Designer 2010. A site customization never requires touching the front-end Web server.

SharePoint development, on the other hand, involves working with farm solutions that include files that must be deployed to the file system of the front-end Web server. In Chapter 2, we introduce SharePoint solutions and discuss best practices for how to package a development effort for deployment within a SharePoint 2010 farm.

Windows PowerShell Boot Camp for SharePoint Professionals

SharePoint 2010 is the first version of SharePoint technologies for which Microsoft supports administration through Windows PowerShell scripts. In SharePoint 2007, farm administrators use a command-line utility named stsadm.exe to run interactive commands from the console window and to write MS-DOS-style batch file scripts to automate common administrative tasks such as creating, backing up, or restoring a new site collection.

SharePoint Foundation still installs stsadm.exe, but it is primarily included to support backward compatibility with scripts migrating from earlier versions. Microsoft now recommends using the new Windows PowerShell support for writing, testing, and executing scripts that automate the same types of administrative tasks that you can accomplish using stsadm.exe, plus a whole lot more.

The Windows PowerShell support for SharePoint Foundation adds a new required skill for every farm administrator and every developer moving from SharePoint 2007 to SharePoint 2010. You're now required to be able to read, write, and execute Windows PowerShell scripts to automate tasks such as creating a new Web application or a new site collection.

Today, scores of SharePoint farm administrators and SharePoint developers have no prior experience in Windows PowerShell. After all, a SharePoint 2007 environment is a place where the squeaky wheel gets the grease. Who has time to learn about something they can't use in their day-to-day activities? It is likely that many of these SharePoint professionals won't learn about Windows PowerShell until they are forced to in their move to SharePoint 2010.

Given the expected percentage of readers without any prior experience with Windows PowerShell, we decided to conclude Chapter 1 with a fast and furious Windows PowerShell boot camp. Our goal here is to get you up to speed on Windows PowerShell so that you can start reading, writing, executing, and debugging Windows PowerShell scripts. So fasten your seatbelt.

Learn Windows PowerShell in 21 Minutes

Working with Windows PowerShell is much easier than writing MS-DOS-style batch files. It's easier because the Windows PowerShell scripting language treats everything as an object. You can create and program against .NET objects as well as COM objects. Furthermore, Windows PowerShell has first-rate support for calling out to EXE-based utilities and passing parameters to execute specific commands.

There are two common ways in which you can use Windows PowerShell. First, you can execute commands interactively using the Windows PowerShell console window. Second, you can write scripts to automate administration tasks. Then you can execute these scripts either on demand or through some type of scheduling mechanism.

Let's start by getting familiar with the Windows PowerShell console window. You can launch the Windows PowerShell console window from the following path in the Windows Start menu.

Start\All Programs\Accessories\Windows PowerShell\Windows PowerShell

When the Windows PowerShell console appears, you should type and execute the following three commands interactively.

1. Type cd\ and then press Enter. This sets the current location to the root of the C:\ drive.

2. Type cls and then press Enter. This clears the console window.

3. Type 2 + 2 and then press Enter. This performs a mathematical calculation and displays the result.

If you followed these steps correctly and executed each of the three commands, your console window should look like the one in Figure 1-13.

Figure 1-13: You can execute commands interactively from the Windows PowerShell console window.

Congratulations! You've just completed your first lesson. Now you know how to execute a command interactively from the Windows PowerShell console window. You simply type the command at the cursor in the Windows PowerShell console window and press the Enter key.

Windows PowerShell is based on reusable libraries containing functions known as cmdlets (pronounced "command lets"). Cmdlets have names that follow the convention of a common verb followed by a noun. For example, the built-in Windows PowerShell libraries provide a cmdlet named Get-Process, which returns a collection of objects representing the Windows processes running on the current machine.

PS C:\> Get-Process

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    599       0      108        300     3               4 System
   2683    6161    85248      84996   124     0.39   1648 dns
    568      63    16240      30584   169     1.28   3888 explorer
    588      48    29492      41536   191     1.17    848 iexplore
    146      21    22168      28552    97     0.25   1680 inetinfo
   1805     231    30220      32364   243     2.00    580 lsass
    765      74    98828      79176   740     2.64   2892 OWSTIMER
    270      22    64564      60460   569     0.83   3432 powershell
    791      82   167088      98088 -1604     4.11   2368 ReportingServicesService
    733     597   278316     153224 -1592     3.97   2024 sqlservr
    977     135   173372     180504  1511     4.94   2176 w3wp
    773     123   161220     164464  1485     3.36   5112 w3wp
    270      31    25052      17860   496     0.14   2568 WSSADMIN

Pipelining is an important concept to understand when executing cmdlets. The basic idea is that every cmdlet returns an object or a collection of objects. Pipelining allows you to take the results of one cmdlet and pass it to a second cmdlet. The second cmdlet can run and then pass its results to a third cmdlet, and so on. You create a pipeline by typing a sequence of cmdlets separated by the | (pipe) character.

cmdlet1 | cmdlet2 | cmdlet3

Let's examine a common scenario in which you need to create a pipeline of two cmdlets to filter a collection of objects. First you call Get-Process to return a collection of objects, and then you use pipelining to pass this collection of objects to the Where-Object cmdlet.

PS C:\> Get-Process | Where-Object {$_.ProcessName -like "w*"}

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    977     135   173372     180504  1511     4.94   2176 w3wp
    773     123   161220     164464  1485     3.36   5112 w3wp
    270      31    25052      17860   496     0.14   2568 WSSADMIN

The Where-Object cmdlet takes a predicate expression enclosed in curly braces as a parameter. Inside these curly braces, you can use $_ to refer to an object as it's being filtered. The predicate expression in this examples is {$_.ProcessName -like "w*"}. The filter returns all processes whose process name starts with "w".

Windows PowerShell cmdlets such as Where-Object use standard Windows PowerShell Comparison operators. You should memorize these operators because you'll be using them regularly as you work with Windows PowerShell. Table 1-4 lists some commonly used Windows PowerShell comparison operators.

Table 1-4 Commonly Used Windows PowerShell Comparison Operators

Operator	Purpose
-lt	Less than
-le	Less than or equal to
-gt	Greater than
-ge	Greater than or equal to
-eq	Equal to
-ne	Not equal to
-like	Like using wildcard matches
-notlike	Not like using wildcard matches

You should understand that Windows PowerShell comparison operators that work with strings are case insensitive by default. However, these operators can be made case sensitive by adding a c immediately after the hyphen. For example, -ceq represents the case-sensitive equal-to operator.

Writing Windows PowerShell Scripts

Now that you've seen how to execute cmdlets from the Windows PowerShell console window, it's time to move on to Windows PowerShell scripting. Windows PowerShell scripts are text files that have an extension of .ps1. You can create and edit a Windows PowerShell script using any text editor, including notepad.exe.

Before you can begin writing and testing Windows PowerShell scripts, you must adjust the Windows PowerShell script execution policy on your developer workstation. The reason for this step is that Windows PowerShell is configured out of the box to prohibit or to prompt the user during script execution. On a developer workstation, it's common to disable the default execution constraints so that you can write and test scripts without security errors. You make this adjustment by calling the Set-ExecutionPolicy cmdlet from the Windows PowerShell console to set the current machine's execution policy to "bypass".

Set-ExecutionPolicy "bypass"

Once you've correctly adjusted the Windows PowerShell execution policy, you can write your first script. Open Notepad.exe, and type in the following one-line script.

Write-Host "Hello World"

Now you need to save the file for the script with a .ps1 extension. First, create a new directory named Scripts on your local C:\ drive. Next, save your new Windows PowerShell script file as c:\Scripts\Script1.ps1. Now that you've saved the Windows PowerShell script file with a .ps1 extension, you can execute the script to test your work.

Let's first execute the script through the Windows PowerShell console window. In the console window, move to the new directory by executing Set-Location c:\Scripts. Now you can execute the script by typing .\Script1.ps1 and pressing Enter. When you do this, you should be able to see the message Hello World in the Windows PowerShell console window.

Now let's create a Windows batch file so that you can execute the script without having to use the Windows PowerShell console window. Just create a new text file named RunIt.bat in the same directory as Script1.ps1, and call powershell.exe and pass the -Command parameter with the following syntax to execute the script.

powershell.exe -Command "& {.\Script1.ps1}"
pause

Notice that this example batch file also added a pause operation at the end. This can be handy because it keeps the MS-DOS console open so that you can see the output of your Windows PowerShell script.

Finally, you should learn how to directly execute a Windows PowerShell script without any assistance from an MS-DOS batch file. If you right-click on a Windows PowerShell script such as Script1.ps1 in Windows Explorer, you'll see a menu command with the caption Run with PowerShell. If you execute this command, the Windows operating system takes care of executing the Windows PowerShell script for you.

Executing Windows PowerShell scripts by using the Run with PowerShell command is quick and easy, but it doesn't leave the Windows PowerShell console window open when it's done. If you like using this technique but you still want to see the Windows PowerShell console Window afterward, you can simply add the Read-Host cmdlet at the bottom of your script.

Write-Host "Hello World"
Read-Host

The Windows PowerShell Integrated Scripting Environment (ISE)

Although you can use any text editor you'd like to write Windows PowerShell scripts, you should prefer to use a powerful new utility, the Windows PowerShell Integrated Scripting Environment (ISE), which is included with the Windows operating system. The Windows PowerShell ISE is shown in Figure 1-14.

Figure 1-14 You should write Windows PowerShell scripts using the Windows PowerShell Integrated Scripting Environment (ISE).

SharePoint Foundation installs the Windows PowerShell runtime but doesn't automatically install the Windows PowerShell ISE. You need to explicitly install the Windows PowerShell ISE on your development workstation. In Windows Server 2008 and Windows Server 2008 R2, you enable the Windows PowerShell ISE feature through Server Manager. With Windows 7, you install the Windows PowerShell ISE through the Windows Control Panel.

The Windows PowerShell ISE will be immediately familiar to anyone with experience in Visual Studio. You can type a script in the top window and then press the F5 key to execute the script in debug mode. The Windows PowerShell ISE allows you to debug by setting breakpoints and to single-step through your code. Once you've launched the Windows PowerShell ISE, type the following script into the top window and then press F5.

$sum1 = 2 + 2
$sum2 = 3 + 4
$sum3 = $sum1 + $sum2
Write-Host $sum3

This example shows how to create a new variable in a Windows PowerShell script. You simply create a new variable name, which begins with the $ character. You don't need to define variables before you use them, as you do in C#. Instead, you just create a variable when you begin using it.

Now, let's write a Windows PowerShell control of flow construct. In this case, we create a new string array using the proper Windows PowerShell syntax and then write a foreach loop to enumerate each string.

$band = "Paul", "John", "George", "Ringo"
foreach($member in $band) {
  Write-Host $member
}

One aspect of Windows PowerShell that will instantly appeal to .NET developers is that you can create and program against any .NET object. For example, imagine you want to create an object from the DateTime class of the .NET Framework. You do this by executing the New-Object cmdlet and passing the class name and initialization values as parameters.

$date = New-Object -TypeName System.DateTime -ArgumentList @(1882,7,4,0,0,0) 
$message = "Wingtip Toys, Inc. was founded on " + $date.ToLongDateString()
Write-Host $message

The preceding script produces the following output.

Wingtip Toys, Inc. was founded on Tuesday, July 04, 1882

In addition to creating new .NET objects, Windows PowerShell allows you to call the static methods and static properties of classes in the .NET Framework. You do this by typing the namespace-qualified class name in square brackets, like this: [System.DateTime]. After you type the class name, you add the :: operator (two colons) and then the call to a static member.

$today = [System.DateTime]::Today
Write-Host $today.ToLongDateString()
Write-Host $today.ToString("MM/dd/yy")
Write-Host $today.AddDays(100).ToString("MMMM d")

If you're feeling nostalgic, you can even use Windows PowerShell to create and program against COM objects. For example, let's say you want to write a Windows PowerShell script that launches Internet Explorer and navigates to a specific URL. The Windows operating system provides a built-in COM interface that allows you to launch and control Internet Explorer.

$ie = New-Object -ComObject "InternetExplorer.Application"
$ie.Navigate("http://intranet.wingtip.com")
$ie.Visible = $true

The SharePoint PowerShell Snap-in

Windows PowerShell installs a set of core libraries containing cmdlets such as Write-Host, Get-Process, and Where-Object. Environments like SharePoint Foundation add their own custom cmdlet library by installing a Windows PowerShell snap-in. When you install SharePoint Foundation, a core Windows PowerShell snap-in named Microsoft.SharePoint.PowerShell is installed. However, you have to ensure that Microsoft.SharePoint.PowerShell is loaded before you begin to call its cmdlets.

SharePoint Foundation provides a specialized version of the Windows PowerShell console known as the SharePoint 2010 Management Shell. You can launch the SharePoint 2010 Management Shell from a shortcut that SharePoint Foundation adds to the Windows Start menu.

All Programs\Microsoft SharePoint 2010 Products\SharePoint 2010 Management Shell

The main difference between the standard Windows PowerShell console window and the SharePoint 2010 Management Shell console has to do with what Windows PowerShell Providers get loaded automatically. More specifically, the SharePoint 2010 Management Shell automatically loads the SharePoint provider named Microsoft.SharePoint.PowerShell while the standard Windows PowerShell console does not. In general, you can't always rely on Microsoft.SharePoint.PowerShell being loaded automatically, so you need to learn how to load it explicitly within a Windows PowerShell script.

Let's say you've just launched the standard Windows PowerShell console window and you attempt to execute one of the cmdlets built into SharePoint Foundation, such as Get-SPWebApplication. The call to this cmdlet will fail unless you've already loaded the SharePoint PowerShell snap-in Microsoft.SharePoint.PowerShell. Before calling the Get-SPWebApplication cmdlet, you need to load the SharePoint Foundation PowerShell snap-in using the Add-PSSnapin cmdlet.

Add-PSSnapin Microsoft.SharePoint.PowerShell
Get-SPWebApplication

Executing these two cmdlets in sequence displays the current collection of Web applications for the current farm excluding the Web application for SharePoint 2010 CentralAdministration.

DisplayName                    Url
-----------                    ---
Wingtip Intranet               http://intranet.wingtip.com/
Wingtip Extranet               http://extranet.wingtip.com/
Wingtip Public Web site        http://www.wingtip.com/

One thing to keep in mind is that a call to Add-PSSnapin will fail if the SharePoint snap-in is already loaded. Therefore, you might want to play it safe and check to see whether the snap-in is already loaded before attempting to load it.

$snap = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'}
if ($snap -eq $null) {
  Add-PSSnapin Microsoft.SharePoint.Powershell
}

Of course, if you just want to get rid of the error message, you can get the same effect with less typing by calling Add-PSSnapin using the ErrorAction parameter with a value of SilentlyContinue.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue"

Now let's write a Windows PowerShell script to create a new Web application. You can do this by calling the New-SPWebApplication cmdlet. The call requires quite a few parameters.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue"

$name = "Wingtip Testing Web App"
$port = 1001
$hostHeader = "intranet.wingtip.com"
$url = "http://intranet.wingtip.com"
$appPoolName = "SharePoint Default Appl Pool"
$appPoolAccount = Get-SPManagedAccount "WINGTIP\SP_WorkerProcess"

New-SPWebApplication -Name $name -Port $port -HostHeader $hostHeader -URL $url  
                     -ApplicationPool $appPoolName 
                     -ApplicationPoolAccount $appPoolAccount

Notice that the call to the New-SPWebApplication cmdlet in the preceding script breaks across multiple lines for clarity. When you write scripts, however, you must place a call to a cmdlet and all its parameters on a single line.

As you can imagine, writing and executing scripts like this can save quite a bit of time in a production farm because the need to perform the same tasks manually through SharePoint 2010 Central Administration is eliminated. Scripts like this also create a great way to create consistency in how you create Web applications across farms.

We'll finish with one more example. Let's write a script to create a new site collection in the Web application we created earlier, which has a Team site as its top-level site. You can accomplish this by calling the New-SPSite cmdlet.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue"

$title= "Wingtip Dev Site"
$url = "http://intranet.wingtip.com:1001"
$owner = "WINGTIP\Administrator"
$template = "STS#1"

New-SPSite -URL $url -Name $title -OwnerAlias $owner -Template $template

When you create a new site collection using the New-SPSite cmdlet, you must specify the URL and title and provide a user account to be configured as the site collection owner. You can also specify a template using the Template parameter, which is applied on the top-level site. In this example, a template of STS#1 has been applied to create the top-level site as a standard Team site.

Now we've written a script to create a new site collection. The first time you run it, it works great. But what happens when you run it a second time? The second attempt to call the New-SPSite cmdlet fails because a site collection already exists at the target URL.

During development, there's a common scenario in which you must continually delete and re-create a site to effectively test and debug your code. Before deleting a site collection, your script should check to see whether a target site collection already exists at the target URL by using the Get-SPSite cmdlet. If the site collection already exists, you can delete it with the Remove-SPSite cmdlet.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue"

$title= "Wingtip Dev Site"
$url = "http://intranet.wingtip.com:1001"
$owner = "WINGTIP\Administrator"
$template = "STS#1"

# delete target site collection if it exists
$targetSite = Get-SPSite | Where-Object {$_.Url -eq $url}
if ($targetSite -ne $null) {
  Remove-SPSite -Identity targetSite -Confirm:$false
}

# create new site collection
New-SPSite -URL $url -Name $title -OwnerAlias $owner -Template $template

Remember that cmdlets such as New-SPSite return objects that you can program against. For example, imagine you want to update the title of the top-level site after the site collection has been created. A site collection object exposes a RootWeb property that allows you to access the top-level site. The site object provides a Title property you can modify with a new title. You must call the site object's Update method to write your changes back to the content database.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction "SilentlyContinue"

$title= "Wingtip Dev Site"
$url = "http://intranet.wingtip.com:1001"
$owner = "WINGTIP\Administrator"
$template = "STS#1"

# delete target site collection if it exists
$targetSite = Get-SPSite | Where-Object {$_.Url -eq $url}
if ($targetSite -ne $null) {
  Remove-SPSite -Identity targetSite -Confirm:$false
}

$sc = New-SPSite -URL $url -Name $title -OwnerAlias $owner -Template $template
$site = $sc.RootWeb
$site.Title = "My New Site Title"
$site.Update

You've just seen an example of writing code against the server-side object model of SharePoint Foundation. Unfortunately, the Windows PowerShell ISE isn't able to provide IntelliSense in the same manner as Visual Studio does. However, the Windows PowerShell ISE still has valuable editing and debugging features that are easy to learn and use. You should become familiar with this tool because it provides a quick way to script out changes to the local farm in your development workstation or in a production environment.

Conclusion

SharePoint Foundation represents different things to different people. To users, SharePoint Foundation provides the infrastructure for Web-based business solutions that scale from simple team collaboration sites to enterprise-level applications. To site collection administrators, SharePoint Foundation provides the capability to customize sites by adding lists and document libraries and by customizing many aspects of a site's appearance through the browser or by using a customization tool such as SharePoint Designer 2010.

To a company's IT staff, SharePoint Foundation provides a scalable and cost-effective solution for provisioning and managing a large number of sites in a Web farm environment. It also provides a reliable mechanism to roll out applications and to version these applications over time.

To a developer, SharePoint Foundation represents a rich development platform that adds value on top of the underlying ASP.NET platform. Developers build software solutions targeting SharePoint Foundation using features and components such as Web Parts, event handlers, and workflows. Now that you've studied the SharePoint developer roadmap and made it through our PowerShell boot camp, you're ready to dive into the fundamentals of SharePoint Foundation development.

Additional Resources

For more information, see the following resources:

• Chapter 2: SharePoint Foundation Development (Inside SharePoint 2010)

• Chapter 3: SharePoint Developer Tools in Microsoft Visual Studio 2010 (Inside SharePoint 2010)

• Chapter 4: Sandboxed Solutions (Inside SharePoint 2010)

• SharePoint 2010

• SharePoint Server 2007

• SharePoint Developer Center

About the Authors

• Ted Pattison is an author, instructor, and co-founder of Critical Path Training, a company dedicated to education on SharePoint technologies. As a Microsoft SharePoint Most Valuable Professional (MVP), Ted frequently works with the Microsoft Developer Platform Evangelism group to research and author SharePoint training material for developers early in the product life cycle while in its alpha and beta stages. Ted also writes a developer-focused column for MSDN Magazine titled Office Space.

• MVP Andrew Connell is an author, instructor, and co-founder of Critical Path Training, a SharePoint education-focused company. Andrew is a six-time recipient of Microsoft’s Most Valuable Professional (MVP) award (2005-2010) for Microsoft Content Management Server (MCMS) and Microsoft SharePoint Server. He authored and contributed to numerous MCMS and SharePoint books over the years including his book Professional SharePoint 2007 Web Content Management Development by WROX. Andrew speaks about SharePoint development and WCM at conferences such as Tech-Ed, SharePoint Connections, VSLive, SharePoint Best Practice Conference, SharePoint Evolutions Conference, Office Developer Conference, and Microsoft SharePoint Conference in the United States, Australia, England, and Spain. Andrew blogs at Andrew Connell Blog and on Twitter @andrewconnell.

• Scot Hillier is an independent consultant and Microsoft SharePoint Most Valuable Professional (MVP) focused on creating solutions for Information Workers with SharePoint, Office, and related .NET Framework technologies. He is the author/coauthor of 15 books and DVDs on Microsoft technologies, including Inside Microsoft SharePoint 2010 and Professional Business Connectivity Services. Scot splits his time between consulting on SharePoint projects, speaking at SharePoint events like Tech-Ed, and delivering training for SharePoint developers. Scot is a former U.S. Navy submarine officer and graduate of the Virginia Military Institute. Scot can be reached at scot@shillier.com.