Whatever configuration you choose, you should try to develop on your own server machine. That's the only way to get the Visual Studio 2010 F5 deployment feature. It makes your development cycles shorter and increases productivity.

For a team-working arrangement there are several extra prerequisites. SharePoint 2010 is a 64-bit–only product. That means your whole environment must run on 64 bits. If this is overkill, there are alternatives. We strongly recommend setting up a virtual server on a physical machine, such as Hyper-V or VMware on Windows Server 2008. Create your virtual development machines there and access them remotely. A cheap Windows 7 machine will suffice as such a client computer. SharePoint projects occasionally crash the server during heavy development. Re-creating a virtual machine is much easier than losing your whole personal computer.

The following list is the minimum needed for a working SharePoint development system. Depending on your specific needs, you may need to install additional components. The order is obligatory—meaning that SharePoint must be installed before Visual Studio. The help files are, of course, optional.

The server is now ready to act as a powerful development machine.

The following section details the more complicated process to install SharePoint on Windows Vista or Windows 7. These instructions are intended for professional developer workstations and follow Microsoft's recommendations for such a development environment running Visual Studio 2010 and SharePoint Server 2010 on the same machine.

There are two limitations with this development environment: you cannot create a SharePoint 2010 farm, and SharePoint 2010 must not run in production on Windows Vista or Windows 7.

Be sure to run all the installation steps as a local machine administrator.

The recommended machine configuration is

Start with the SharePoint.exe file for SharePoint Foundation or SharePoint Server 2010. Extract the files from SharePoint.exe with the following command line. A user account control (UAC) prompt might appear at this point.

SharePoint.exe /extract:c:SharePointFiles

This extracts all of the installation files to your hard drive. Use a folder you can recognize easily later, such as c:SharePointFiles. This allows you to repeat the installation steps without extracting the package again and enables access to the configuration file that needs tweaking, to permit installation on Windows Vista or Windows 7:

c:SharePointFilesFilesSetupconfig.xml

Add the following line to the end of the config.xml file:

<Setting Id="AllowWindowsClientInstall" Value="True"/>

The complete file should now look like this:

<Configuration>
  <Package Id="sts">
    <Setting Id="SETUPTYPE" Value="CLEAN_INSTALL" />
  </Package>
  <DATADIR Value="%CommonProgramFiles%Microsoft SharedWeb Server

Extensions14Data" />
  <Logging Type="verbose" Path="%temp%" Template="Microsoft Windows
                                        SharePoint Services 4.0 Setup *.log" />
  <Setting Id="UsingUIInstallMode" Value="1" />
  <Setting Id="SETUP_REBOOT" Value="Never" />
  <Setting Id="AllowWindowsClientInstall" Value="True"/>
</Configuration>

If you miss this step, you will see an error dialog, as shown in Figure 1-1, when you run the installation.

Figure 1.1. Error if the package is not altered to run with Windows 7

Before running the SharePoint setup, install the prerequisites described in the "Installing Required Windows Features" section of this chapter.

These three components are not required on Windows 7, because they are included with the operating system. For Vista with no service pack or SP1 only, they are required.

First, install the .NET Framework 3.5 SP1 from http://download.microsoft.com/download/2/0/e/20e90413-712f-438c-988e-fdaa79a8ac3d/dotnetfx35.exe.

Second, install PowerShell x64 from www.microsoft.com/downloads/details.aspx?FamilyID= af37d87d-5de6-4af1-80f4-740f625cd084.

Third, install the Windows Installer 4.5 redistributable from www.microsoft.com/downloads/details. aspx?FamilyID=5a58b56f-60b6-4412-95b9-54d056d6f9f4.

The SharePoint 2010 prerequisite installer does not run on Windows Vista or Windows 7. You must manually configure the necessary Windows features and install the requisite software. The requirements include enabling almost all the IIS (Internet Information Services) features. Instead of checking almost all the boxes in the IIS section in Windows Features, you can enable them programmatically. At a command prompt, paste in the following command (for clarity the options are shown line by line, though you're supposed to enter them as a single line):

start /w pkgmgr /iu:IIS-WebServerRole;                          IIS-WebServer;
IIS-CommonHttpFeatures;                                         IIS-StaticContent;
IIS-DefaultDocument;                                            IIS-DirectoryBrowsing;
IIS-HttpErrors;                                                 IIS-ApplicationDevelopment;

IIS-ASPNET;                                                     IIS-NetFxExtensibility;
IIS-ISAPIExtensions;                                            IIS-ISAPIFilter;
IIS-HealthAndDiagnostics;                                       IIS-HttpLogging;
IIS-LoggingLibraries;                                           IIS-RequestMonitor;
IIS-HttpTracing;                                                IIS-CustomLogging;
IIS-Security;                                                   IIS-BasicAuthentication;
IIS-WindowsAuthentication;                                      IIS-DigestAuthentication;
IIS-RequestFiltering;                                           IIS-Performance;
IIS-HttpCompressionStatic;                                      IIS-HttpCompressionDynamic;
IIS-WebServerManagementTools;                                   IIS-ManagementConsole;
IIS-IIS6ManagementCompatibility;                                IIS-Metabase;
IIS-WMICompatibility;                                           WAS-WindowsActivationService;
WAS-ProcessModel;                                               WAS-NetFxEnvironment;
WAS-ConfigurationAPI;

This may take some time. When it is finished, your Windows Features dialog settings should look like Figure 1-2.

Figure 1.2. Check the prerequisites required for SharePoint 2010

A reboot is required after the Windows Features update. Next, install FilterPack by running the command:

c:SharePointFilesPrerequisiteInstallerFilesFilterPackFilterPack.msi

This command runs a Windows installer application. There are no configuration steps—it simply installs its contents.

Install Windows Identity Foundation (WIF). This framework was formerly known by the code name Geneva. This is an update package and it's described in Knowledge Base article KB974405. It also has no configuration settings. The SharePoint Foundation needs the Microsoft.IdentityModel assembly with version 1.0.0.0.

Now you're ready to install SharePoint 2010 using setup.exe. After the start screen, you must accept the license terms. In the next step, choose Standalone as the server type, as shown in Figure 1-3.

Click Install Now to start the installation.

Figure 1.3. Choose a Standalone installation.

When the installer ends, you will be prompted to optionally start the SharePoint Products and Technologies Configuration wizard. With the check box checked, click Close to run it, as shown in Figure 1-4.

Figure 1.4. Run the configuration wizard.

The wizard leads you through several steps:

If the configuration is successful, you should install SQL Server 2008 SP1. If you install Visual Studio 2010 in the next step, this is not required, as the current release comes with the required service packs for SQL Server 2008 Express.

When it finishes, create a new SharePoint site using SharePoint 4.0 Central Administration under Administrative Tools.

Now install Visual Studio 2010 and the SharePoint development tools. The tools add several useful templates for creating SharePoint objects. The installation is straightforward, though you'll need to restart the computer once in the middle of the installation cycle.

This book will explain the API as deeply and broadly as space allows. However, even that will not be enough. We'll even point to the entry points within the official documentation on MSDN. That's not enough either. If you need to know how something works internally to understand how to use it (instead of reinventing the wheel), use a tool like Reflector—it is priceless. Reflector is a free download from Red Gate—originally written by Lutz Roeder—and is able to decompile .NET code and reformat it into a few common languages, such as C#. Figure 1-7 shows Reflector in action.

There are some exceptions, but almost all major parts of SharePoint 2010 are written in .NET, and you can peek into the code and learn the Microsoft internals.

Figure 1.7. Red Gate's Reflector in action

Whatever your intention and whatever sort of code you're about to write, the API is your partner. Using the SharePoint controls and methods is the recommended approach. You can extend, customize, reformat, configure, preset, and generally do whatever you want with the existing components. But never reinvent something and write your own as long as you can find something comparable inside SharePoint. These components fit very well into the platform and they have many useful features. Adopting and changing is almost always better than writing your own from scratch.

Only if you can't find anything usable within SharePoint should you consider backing up a step and trying an ASP.NET component. Imagine a table you wish to use to present some data. First, try the SPGridView control. It's feature rich, and end users know it because it's the standard control used to present lists. It has such features as sorting and grouping. It's almost public, so you can easily hook into the interfaces and events and customize it. It's there for you. Only after you've experimented with customizing the SPGridView control and found it inadequate for your purposes should you try its base class, GridView, from ASP.NET. It might be simpler, but you can add your own features more easily. If even this fails, use the .NET Framework and write your own grid.

Once you have adopted, customized, and modified a component, think about team productivity. Repackage your component as another custom component, add configuration features, and make it installable. Redistribute it in your team and encourage others to make use of it. That way you ensure that your colleagues struggling with the API do not stray from the recommended approach.

The event log (see Figure 1-8) contains a special section for SharePoint, and the application event log can also contain some relevant information. It is even worth looking for events sent here from IIS. If the SharePoint application causes the worker process to die ungracefully, it can help to know when and why.

Figure 1.8. The SharePoint event log is now part of the Windows Event Viewer.

SharePoint itself writes a lot of data into the logs if it is enabled in Central Administration. During the development and test cycle, we strongly recommend activating the logs. You can find the logging files in

<%CommonProgramFiles%>Microsoft SharedWeb Server Extensions14LOGS

The IIS logs are found here:

<%SystemRoot%>System32LogFiles

The IIS logs contain information about each request and the response. If you match certain reactions of SharePoint with the event of a specific request, there is a good chance of finding the reason for some unexpected behavior.

If you suspect that your code is causing the misbehavior and the debugger disturbs the data flow, a private trace is a good option. Just write useful information from your code to a trace provider. You can turn tracing on and off by setting the appropriate options in the application's web.config file:

<configuration>
 <system.web>
  <trace enabled="true" requestLimit="40" localOnly="false"/>
 </system.web>
</configuration>

The tracing framework is highly extensible and you can write the data to text files, the event log, or databases, or as XML. A full explanation is beyond the scope of this book. You can start here to learn more about tracing using the .NET Framework:

http://msdn.microsoft.com/de-de/library/1y89ed7z(en-us,VS.85).aspx

In addition to these specific techniques, you should consider using advanced .NET debugging methods such as the following:

These methods are not SharePoint-specific, but are nonetheless quite helpful.

By default the Developer Dashboard is switched off. To activate it on your machine, you can run a stsadm command:

stsadm -o setproperty -pn developer-dashboard -pv ondemand

The command switch -pv accepts the following settings:

The ondemand option is usually the best choice, as it allows you to show or hide the information using the dashboard icon in the upper-right corner, as shown in Figure 1-9.

Figure 1.9. The icon to show the dashboard on demand

The on option is helpful if the layout of a page is destroyed or you can't reach the Dashboard icon for some reason.

To activate the Developer Dashboard via PowerShell, use a script such as this:

$level="Off"
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[void][System.Reflection.Assembly]::LoadWithPartialName
                                    ("Microsoft.SharePoint.Administration")
$contentSvc=[Microsoft.SharePoint.Administration.SPWebService]::ContentService
$contentSvc.DeveloperDashboardSettings.DisplayLevel=
                ([Enum]::Parse(
                [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel],
                $level))
$contentSvc.DeveloperDashboardSettings.Update()
Write-Host("Current Level: " + $contentSvc.DeveloperDashboardSettings.DisplayLevel)

The supported properties for the $level variable are the same as those for stsadm:

This code is good for running in a batch file using a parameter. To copy a command-line parameter to the variable, use something like this:

param($level)

There is neither error handling nor user help in this batch file. Consider adding such lines to turn this sample batch file into production-quality code.

You're probably going to write some clever tools for SharePoint. Using code to activate the dashboard may help others to investigate what they are doing. A simple piece of code does the trick:

SPWebService svc = SPWebService.ContentService;
svc.DeveloperDashboardSettings.DisplayLevel = SPDeveloperDashboardLevel.OnDemand;
svc.DeveloperDashboardSettings.Update();

Note that the usage of the SPFarm object, which is shown in several blogs regarding earlier versions of SharePoint 2010, is no longer supported in the final SharePoint product.

This tool will give you the following:

Use this information to narrow down the source of any error (see Figure 1-10).

Figure 1.10. The Developer Dashboard reveals internal information.

To access the dashboard, click the icon in upper-right corner to the left of the help button question mark. The dashboard analyses the current page only. The underlying ASP.NET engine has a lot more information beyond what the dashboard shows. It is written to the file Trace.axd, and can be displayed by clicking the small link at the end of the dashboard screen showing "Show or hide additional tracing information..." (see Figure 1-11).

Figure 1.11. The Developer Dashboard's trace information screen

The ASP.NET trace shows virtually everything available from the current request/response cycle, such as headers, cookies, and form data. This includes internal traces, stack traces, and names of stored procedures and the time that they appeared. That makes the dashboard not only a perfect tool to find errors, but even more helpful to find performance flaws. The complete control tree is exposed and makes it possible to find the reason an element is not where you expect it or why it is missing altogether.

The dashboard displays any useful information that's available from the runtime environment. However, the reason for a malfunction, bad performance, or unexpected behavior could be in your code. It's good practice, in addition to using debugging tools, to add diagnostic output to your code that generates content to the dashboard.

You can use the SPMonitoredScope class to create a section that is logged and explicitly exposed to the dashboard's output.

Let's assume you create a visual Web Part and you want to know what happens inside the Load event, when is it called, and how much time a specific operation consumes. The following code explains how to use the SPMonitoredScope class:

using System;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Utilities;

namespace VisualWebPartDashboard.VisualWebPart1

{
    public partial class VisualWebPart1UserControl : UserControl
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            using (SPMonitoredScope scope =
                   new SPMonitoredScope(this.GetType().Name))
            {
                Button b = new Button();
                b.Text = "Click me!";
                Controls.Add(b);
                using (SPMonitoredScope scopeInner =
                       new SPMonitoredScope("Inner Scope"))
                {
                    System.Threading.Thread.Sleep(500); // lengthy operation
                }
            }
        }
    }
}

In this code, the SPMonitoredScope class exposes two lines to the dashboard output. The first uses the current internal name of the control, while the second uses a constant string. The inner operation is delayed to show the effect of the timer.

The advantage of this method is that the output appears within the context of the execution tree, and you see not only your information, but also when your code is executed. You can also see in Figure 1-12 how the artificial 500-millisecond delay in the code affects the whole page.

Figure 1.12. Private information shown in the Developer Dashboard

Sniffing the protocol activity on the connection with SharePoint requires a tool like Fiddler (see Figure 1-13). It shows the data flow, headers, cookies, and raw data sent down to the server and back to the browser. Fiddler is a web-debugging proxy that sits between the browser and the network socket. It logs all incoming HTTP (and HTTPS) traffic. You can inspect the headers received and sent, investigate the raw data, and edit data to test your server. Fiddler itself is independent of a specific browser and works well with Internet Explorer, Firefox, Opera, and others. For advanced scenarios, Fiddler can be extended using .NET-based plug-ins to automate traffic analysis. There are several add-ons available.

Figure 1.13. Fiddler snagging traffic

SharePoint makes heavy use of Ajax. Such calls to the server (called postbacks) run in the background. Fiddler is able to sniff this traffic and show what—if anything—happens.

To start Fiddler, you can use the icon that appears in the toolbar of Internet Explorer (

Figure 1.14. Proxy settings for Fiddler to get incoming and outgoing traffic

When you close Fiddler, it unregisters itself automatically and restores previous settings.

Fiddler supports breakpoints. Because there is now code, breakpoints are based on conditions. If an incoming response or outgoing request matches your criteria, Fiddler will pause, allowing you to investigate the data further.

Fiddler has one serious limitation when sniffing local traffic—a common situation when debugging SharePoint. IE and the .NET Framework are hard-coded to not send requests for localhost through any proxies, and as a proxy, Fiddler will not receive such traffic. The workaround is to use your machine name as the hostname instead of localhost or 127.0.0.1. So, for instance, rather than navigating to http://localhost/Default.aspx, instead visit http://machinename/Default.aspx.

The latest version of Fiddler also supports some other monikers such as http://ipv4.fiddler to reach localhost on the IPv4 adapter, or http://ipv6.fiddler to access localhost on the IPv6 adapter. This works especially well with the Visual Studio 2010 internal web server, which is internally using the IPv4 loopback adapter.

Eventually the page is rendered in the browser. If the rendered page does not display correctly, you will need to check the HTML, styles, and resources. The Internet Explorer Developer Toolbar will unlock those and more. You can download a free copy from www.microsoft.com/downloads/details.aspx?familyid=E59C3964-672D-4511-BB3E-2D5E1DB91038&displaylang=en.

Using this add-on you can

To get started with this tool, press F12 when working within Internet Explorer. You will see several tabs that give access to parts of the loaded data (e.g., HTML, CSS, and scripts).

If you use the SharePoint templates and create solutions or features for deploying, everything works well. However, if you start creating regular ASP.NET web applications that simply reference SharePoint and run standalone, the internal debugger and web server will fail. There are some requirements that you can easily fulfill using IIS. For details, refer to the "Handling 64-Bit Quirks" section later in this chapter. For Visual Studio 2010 it turns out that it's not trivial. One solution is to replace the internal web server with IIS, even for debugging purposes. To accomplish this, you have to set a few settings in your project. First, a web site is required. To create one, use IIS Manager. Follow the steps described in the "Configuring IIS to Run with the Right Account" section to set the correct application pool settings. Then configure your project as follows:

You can now start debugging against IIS without worrying about the limitations of the internal web server.

Visual Studio 2010 comes with a set of templates ready to create SharePoint features. Table 1-1 gives an overview and short description of each template. Visual Studio supports SharePoint 2010 completely and SharePoint 2007 for workflow projects only. When you create a new project, you can find the appropriate path under the language selection. SharePoint templates are available for both VB .NET and C#. You can also choose to program against any of the supported .NET Frameworks: 2.0, 3.0, 3.5, or 4.0. This book uses C# as the preferred language, and you must use Framework 3.5.

Table 1.1. SharePoint Project Templates for C# Developers

Name	Icon	Description
Import SharePoint Solution Package		Creates a new solution based on an existing WSP (Windows SharePoint Solution Package)
Sequential Workflow		Creates a new sequential workflow
State Machine Workflow		Creates a new state machine workflow
Event Receiver		Creates an event receiver that handles events fired by SharePoint
Empty Project		An empty project to which you can add any item
Module		Creates a SharePoint module that can contain files
Business Data Connectivity Model		Creates a SharePoint Business Data Connectivity model that makes use of the Business Data Connectivity services.
Content Type		Creates a custom content type
List Definition		Creates a list definition for programmatically built lists
Import Reusable Workflow		Imports an existing declarative workflow from a WSP file created with SharePoint Designer
Site Definition		A template for defining a site programmatically
Visual Web Part		Creates a new web part using a visual designer

Each of these projects allows the addition of several items. Some of the templates are just an empty solution with at least one item predefined.

After choosing the most suitable template, a wizard appears. You can now choose against which site the project is to be deployed for debugging purposes (see Figure 1-16). Visual Studio takes care to deploy the required files and register the assembly in the Global Assembly Cache (GAC).

Figure 1.16. Choose the site the debugger uses for your solution.

The remaining tasks of the wizard depend on the item selected. Clicking Finish will create the project skeleton. As an example let's investigate a new list definition and its various settings. First, check the settings of the project by pressing F4 to open the properties pane (see Figure 1-17).

Figure 1.17. Check the settings for your project.

You can change the site and the assembly deployment target. If the project consists of only ASPX files or resources, you may deploy directly against the web application. If it is an assembly, it must be deployed into the GAC.

If you have a project created by some of the templates shown previously, you can add items from item templates. Apart from those available for any project type, such as Class, you can add SharePoint-specific items, as shown in Table 1-2.

Table 1.2. SharePoint Item Templates for C# Developers

Name	Icon	Description
Visual Web Part		Web Part with an ASCX user control to create the visual part
Web Part		A regular Web Part with no designer support
Sequential Workflow		Creates a new sequential workflow
State Machine Workflow		Creates a new state machine workflow
Event Receiver		Creates an event receiver that handles events fired by SharePoint
Business Data Connectivity Model		Creates a SharePoint Business Data Connectivity model that makes use of the Business Data Connectivity services
Application Page		Adds an application page for highly customized applications
Module		Creates a SharePoint module
Content Type		Creates a custom content type
List Definition		Creates a list definition for programmatically built lists
List Definition from Content Type		Creates a list definition for programmatically built lists based on an existing content type
List Instance		Creates an actual list within a deployable project (the list can contain predefined data)
Empty Element		An empty element you can add code or configuration files to
User Control		An ASP.NET user control for further usage in Web Parts or application pages

Apart from these SharePoint-specific templates, you can add most of the item templates in the Web section to your project, such as JScript files, HTML, and other common resources.

The package contains several folders, even if it is something like a simple list definition. This structure represents a part of SharePoint's 14 hive—the SharePoint root. An item defined in the project is usually not able to act standalone. To deploy, it must be part of a feature or solution package. Hence, the project must meet specific requirements, and the templates take care of this. At least two items are required:

Under the Features folder, you'll find a feature definition as a configuration file. Each feature has a specific name. Just select the predefined name (Feature1) and rename it to whatever you choose. The files under the folder are then automatically renamed. A feature consists of at least an XML file. You could immediately start typing XML to create the feature. However, in a world of designers and graphical user interfaces (GUIs), you can also launch the Feature Designer.

The Feature Designer (see Figure 1-18) is primarily a collection of files comprising the solution. You can decide which files are parts of the feature.

Figure 1.18. The Feature Designer view

The list definition template contains the support files for a list template and a list instance.

There is an import wizard to import workflows created and designed with SharePoint Designer 2010. Power users can now create workflows with SharePoint Designer and export them to a developer. The developer can import them and add further code or include them in a deployment package for further processing.

The common package format *.wsp can now be imported and further used as the basis for a professional development package.

Once the feature and its contents are defined, a package is required to transport the feature to another SharePoint server. You don't need a package to debug your solution; rather, you need one to make the results available to anyone else. A package creates a WSP file that merely consists of the resources, a manifest file, and assemblies. We'll dig deeper into the internals of the package definition in the Chapter 9.

There are several options for building a package and deploying it to the connected server. Deploying directly to the server allows a fast check of your work and provides immediate debugging capabilities.

The build step performs two tasks:

The deploy step includes the build step and performs several more tasks:

There is also a retract option to remove the current solution from SharePoint. Furthermore, the package option isolates the packaging step from the build step to refine the process in case you're hunting a difficult bug.

Administrators can decide per site collection what exactly a power user operating SharePoint Designer is permitted to do. This gives the administrator the opportunity to manage the power users directly and without the need to check their systems for "forbidden" instances of SharePoint Designer.

You can change the required permissions via the "Site permissions" selection on the Site Actions menu. Choose Permission Levels on the ribbon's Permission Tools tab. Click Design to view the permissions associated with this level (see Figure 1-20).

Figure 1.20. By default, the design permissions include usage of SharePoint Designer.

SharePoint Designer communicates remotely using web services; hence, the Use Remote Interfaces permission must be activated.

The new ribbon-based Office 2010 environment is now context sensitive (see Figure 1-21).

Figure 1.21. The ribbon shows colored tabs for context-sensitive commands.

Commands available only for specific elements appear on colorized tabs at the end of the ribbon bar. These tabs may be grouped, and several such tabs may appear. For example, if you edit an image within a Web Part, both the tabs for Web Part and Image Editing become visible.

It's easy to create pages, lists, and workflows (see Figure 1-22). The main screen allows you to browse any items of the currently opened site. For each element type, you can use the ribbon's first group, New, to create one.

Figure 1.22. It's easy to create new lists, libraries, and workflows.

Once created, you can edit all settings of the list, such as the content types, columns, views, and edit forms.

It's easy to create content types and use them immediately for a list or library. You can also associate workflows and set the appropriate forms for editing, viewing, and creating new elements based on this content type (see Figure 1-23).

Figure 1.23. Creating a new content type using SharePoint Designer

Once the content type exists, you can add new columns from the list of site columns.

You can use assets to store and deploy resources such as graphics, stylesheets, and support files. An asset such as a CSS or JavaScript file can be edited directly using the integrated code editor (see Figure 1-24).

Figure 1.24. You can add and edit assets in one step.

By assigning Visual Studio as the default editor, you can also edit files in Visual Studio directly from SharePoint Designer.

You can get the list views as XSLT and modify them by editing the underlying XSLT (see Figure 1-25).

Figure 1.25. Editing a list view reveals the underlying XSLT.

XSLT allows dynamic changes to existing view forms. It's especially helpful when the generated HTML needs adjusting.

You can access external data sources such as web services, databases, XML files, and scripts via the Data Sources option. Any SharePoint list can be used as a data source too. Both SOAP and REST web services are supported.

The new Business Data Connectivity data sources can be easily created, modified, and used. In SharePoint Designer, this option is called External Content Types (that's what it is internally, by the way).

You can create and modify list workflows, site workflows, and reusable workflows. Workflows can be bound to lists or content types.

Two more sections contain all the master pages and sites stored in the database. You can edit any page available in the galleries. However, the editor does not allow any code editing of code-behind files.

This tool configures a fresh SharePoint installation or repairs a damaged one. It's the same as the graphical SharePoint Products and Technologies Configuration Wizard, but the console mode allows it to be executed in batch files for automation purposes.

The most important tool is stsadm.exe. Almost all administrative tasks can be performed using this command-line program. Developers can extend it by adding private commands. It gives your administrators more power without introducing more tools. stsadm was the only automation tool for SharePoint 2007. With SharePoint 2010, Microsoft made a major shift to supporting PowerShell. PowerShell uses so-called cmdlets (pronounced commandlets).

It's important to note that stsadm supports several operations that have no equivalent in the Central Administration or Site Administration UI. That means that unless you program against the API, there is no alternative way to perform certain tasks without using stsadm (or its successors, PowerShell's SharePoint cmdlets). However, using PowerShell is the preferred way, because Microsoft is going to move all administration tools to cmdlets. Sooner or later, Microsoft is going to drop the antiquated batch support, whether you like it or not.

Using SPMetal you can create a proxy class from existing lists and libraries to enable access using LINQ to SharePoint. The tool runs at the command line and can be invoked as a prebuild command within Visual Studio to create base classes for a type-safe data access layer.

This is the common SharePoint Products and Technologies Configuration Wizard that is available after installation and from the Start menu. It supports basic configuration of a fresh installation or repair of an installation that doesn't work.

To prepare ASP.NET for the x64 platform, you need to configure the application pool of your web site. The following exercise shows you how to set the appropriate property, enable32BitAppOnWin64, to false.

Cscript C:inetpubAdminScriptsadsutil.vbs set w3svc/AppPools/Enable32BitAppOnWin64 0

For an ASP.NET application, two settings are required. First, you must set the application pool to run under the administrative account. The following exercise shows you how to configure it.

Next you must ensure that the user you use is able to log onto your web site. You can either edit your web.config file or use the IIS Manager management console. In the web.config file, the following settings apply:

<configuration>
  <system.web>
    <authentication mode="Windows" />
    <authorization>
       <deny users="?" />
    </authorization>
  </system.web>
</configuration>

This code sets ASP.NET to authenticate using Windows authentication. The <authorization> tag prevents anonymous users from accessing the pages. Setting Windows authentication mode via the IIS management console requires the steps shown in the following exercise.

For the authorization part, a similar set of settings are required.

Once everything is done, you can deploy and run your application.