MSDN：Windows SharePoint Services 3.0 中使用代码的开发工具和技术（第 1 部分）

摘要：了解针对 Windows SharePoint Services 3.0 进行开发所需的技能、与传统 ASP.NET 开发的差异、所需的开发环境以及使用 Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 构建 Windows SharePoint Services 解决方案的步骤。本文是两部分中的第一部分。（33 个打印页面）

Patrick Tisseghem, U2U

2007 年 6 月

适用于：Windows SharePoint Services 3.0、Visual Studio 2005 Extensions for Windows SharePoint Services 3.0

目录

• 使用 Windows SharePoint Services 技术进行开发简介

• 所需开发技能

• ASP.NET 应用程序与 SharePoint 网站

• 为 Windows SharePoint Services 开发的内容

• 开发环境

• Visual Studio 2005 Extensions for Windows SharePoint Services 3.0

• 详细了解 Windows SharePoint Services 解决方案

• 关于作者

• 其他资源

使用 Windows SharePoint Services 技术进行开发简介

许 多开发人员急于利用 Windows SharePoint Services 3.0 作为开发平台，以增加协作并为信息工作者构建文档管理解决方案。本文使您深入了解针对 Windows SharePoint Services 进行开发所需的技能、与传统 ASP.NET 开发的差异、所需的开发环境以及使用 Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 构建 Windows SharePoint Services 解决方案的步骤。本文的第二部分探讨 Windows SharePoint Services 解决方案的概念、讲述了解决方案的体系结构以及创建、部署、维护和升级 Windows SharePoint Services 解决方案的技术。本文还包含展示开发人员和管理员可采用的不同方法的演练。

我们首先来了解一下 SharePoint 开发实际上涉及到哪些技术，然后讨论构建、打包、部署和维护 Windows SharePoint Services 解决方案的不同技术。

所需开发技能

人们经常询问 SharePoint 技术开发人员需要掌握哪些技能，并且当他们发现开发人员必须掌握许多技能时，感到很吃惊。

以下是在 SharePoint 开发入门阶段有用的领域列表，从这些领域中可获得所需的专门技术。

ASP.NET 2.0

Windows SharePoint Services 的最新版本和 Microsoft Office SharePoint Server (MOSS) 2007 完全依赖于 Microsoft ASP.NET 2.0 作为基础。因此，对于 Windows SharePoint Services 开发人员来说，熟练掌握 ASP.NET 2.0 概念、术语和开发是头等重要的事。除了了解 ASP.NET 请求的流程、它的不同阶段以及内部体系结构和可扩展性选项，开发人员还必须熟悉开发和使用母版页面、内容页面、ASP.NET 服务器和用户控件、ASP.NET 中的模板、ASP.NET Web 部件及其基础结构和 ASP.NET 提供程序模型。（如果需要快速掌握其中任何一个领域，可以参考许多资源，但这超出了本文的范围。）

Windows Workflow Foundation

在 使用面向信息工作者的 Windows SharePoint Services 解决方案时，您经常必须创建自定义工作流。使用 MOSS 2007 提供的内置工作流在一定程度上满足了业务要求，但通常会要求开发人员使用针对 Windows Workflow Foundation (WF) 和用于构建特定于 SharePoint 工作流的项目模板的扩展构建自定义工作流。为了获得成功，开发人员需要很好地了解 WF，包括构建工作流的过程、构建自定义活动、在工作流中与 SharePoint 环境进行交互等。

XML 技术

Windows SharePoint Services 技术在很大程度上依赖于 XML 技术。这些技术是驱动配置引擎的许多架构定义的基础。其中包括针对网站、列表、文档库、字段、内容类型等的架构定义。在其中大部分架构定义中使用协作应用 程序标记语言 (CAML)。另外，开发人员还必须了解相关的 XML 技术（如 XSLT 和 XPath 技术），因为它们在 Windows SharePoint Services 上的开发中也会遇到这些技术。

Windows SharePoint Services 3.0 和 MOSS 2007 API

Windows SharePoint Services 开发人员必须了解由 Windows SharePoint Services 3.0 和 MOSS 2007 提供的 API。使用 Windows SharePoint Services 构建解决方案需要深入了解对象模型内提供的许多类。另外，如果应用程序针对的是远程使用 SharePoint 技术的智能客户端，开发人员还需要了解 Windows SharePoint Services 和 MOSS 提供的 XML Web 服务知识。

最后，所有的解决方案必须 在一定级别范围（例如，网站集合）的 SharePoint server 服务器场中部署和使用。您必须了解如何打包构成解决方案的不同组件以及如何安装并激活使解决方案对新的和现有网站可用的功能。这篇文章提供了关于如何执行 此操作的详细信息和指南。

ASP.NET 应用程序与 SharePoint 网站

Windows SharePoint Services 开发和传统的 ASP.NET 开发在多方面存在差异。为帮助您了解这些差异，我们可以将 ASP.NET 应用程序与 Windows SharePoint Services 应用程序进行比较。

图 1 显示了主流 ASP.NET 应用程序的不同组件和交互流程。

图 1. 主流 ASP.NET 应用程序的组件和流程

用 户向正在运行 Internet 信息服务 (IIS) 的服务器发送请求，以获得特定资源。IIS 接受这些请求并将其委托给 ISAPI 扩展 DLL 进行进一步处理。通常，从文件系统检索资源，如 config 文件、.aspx 页面、级联样式表、自定义构建 .NET 程序集和用户控件。所有这些都会影响在用户的浏览器中传送给用户的最终响应。在许多应用程序中，还需要与数据存储进行交互以存储和检索用来处理请求和生成 响应的数据。

所以，比较表 1 与表 2（代表基于 Windows SharePoint Services 的网站的组件和流程）后，会发现什么不同呢？

图 2. Windows SharePoint Services 网站上的组件和流程

如图 2 所示，Windows SharePoint Services 从承载高扩展性、模板驱动的网站的详细信息中抽象出了开发人员。在很多情况下，SharePoint 管理员和有经验的用户甚至不接触底层基础结构。然而，对它有所了解还是有帮助的。

Windows SharePoint Services 是网站提供引擎，它严重信赖于对其环境非常重要的多种类型产品模板的构架定义。其中包括网站模板定义、基础结构页面（如组成工作组网站主页的默认 .aspx）定义、列表和库的定义，以及使存储在这些不同容器中的内容进行交互的帮助程序页面的定义。

当开始请求 Windows SharePoint Services 页时，将与配置数据库和内容数据库进行交互以检索请求的详细信息。这包括访问大量包含构架定义的 XML 文件以及访问必须执行其代码（封装在 .NET 程序集中）的构建基块（Web 部件），通过全局程序集缓存或本地 bin 文件夹使得这些 .NET 程序集可用。Windows SharePoint Services 配置引擎连接所有这些过程。

如果您需要一个以上应用程序（也许是 两个、五个甚至几十个），我们再看一下传统的 ASP.NET 应用程序将会发生什么？图 1 开始变得复杂，因为对每个其他应用程序，会重复同样的基础结构。开发人员可以按照最佳实践和模式生成许多可重复利用的构建基块，但是，每次仍必须重新创建 大部分的基础结构。

通过比较，可以看到，可以使用一个公用配置引擎来提供许多 Windows SharePoint Services 网站（几十个、上百个甚至上千个协作网站）。这就是使用 Windoes SharePoint Services 相对于使用 ASP.NET 应用程序的优势。

为 Windows SharePoint Services 开发的内容

Windows SharePoint Services 是一个解决方案平台，这意味着它是可扩展的并可以运行自定义解决方案。以下各部分讨论了 Windows SharePoint Services 开发人员可以构建的解决方案类型。

基于程序集的解决方案

我 们可以将这些解决方案作为基于代码的解决方案来参考。基于程序集的解决方案是使用托管代码（一种 .NET Framework 语言，如 Microsoft Visual C# 或 Microsoft Visual Basic 2005）开发的，并作为 .NET 程序集（一个 DLL）进行编译。您也可以构建这些解决方案的不同类型。下表仅介绍了一些可能的基于程序集的解决方案。

表 1. 基于程序集的解决方案类型

解决方案的类型 说明

Web 部件	SharePoint Web 部件页面的构建基块，用于将特定功能传送到网站的访问者。Web 部件可以执行以下操作：传送来自不基于 Windows SharePoint Services 的存储（如 Microsoft SQL Server 和 Oracle 存储）的数据；捕获数据以驱动业务流程；聚合或累积在 SharePoint 网站中可用的信息，或者执行许多其他功能。默认情况下，许多 Web 部件对于 Windows SharePoint Services 3.0 和 MOSS 2007 是可用的。
事件处理程序	一个 .NET 程序集，包括一个或多个封装代码的类，当 SharePoint 网站中发生特定事件（例如向列表添加项目、创建文档库的卷、删除网站等）时，将执行该程序集。
信息管理策略	MOSS 中一个功能丰富的策略框架，开发人员可以用来构建自定义策略，对在 SharePoint 网站中存储或管理的内容强制执行特定行为。
工作流活动和模板	工 作流是 Windows SharePoint Services 或信息工作者在必须进行的工作流中涉及的活动的集合。有大量的活动可供使用；然而，您可以创建在 .NET 程序集中编译的自定义活动并部署它们，以便具有在 Microsoft Office SharePoint Designer 2007 中创建工作流的经验的用户使用它们。开发人员还可以通过使用 Visual Studio 2005 的工作流扩展来创建工作流模板，并将其作为 .NET 程序集部署到 SharePoint 服务器上。
计时器作业	一些程序集，包含可以由 SharePoint Timer Service 计划和执行的代码。例如，安排在每晚为管理员创建一个报告的作业，报告中显示签出时间超过一周的文档。

ASP.NET 资源

图 2 显示了 Windows SharePoint Services 用来提供网站的基础结构。此基础结构包含了许多 ASP.NET 资源，这些资源可直接使用并有助于提供您使用 Windows SharePoint Services 所具有的简化的开发体验。作为一位开发人员，您可以创建并集成您自己的资源。表 2 介绍了您可以创建的资源的类型。

表 2. ASP.NET 资源的类型

资源 说明

网站页面	存 储在网站集合本身中的文档库中的 ASP.NET 页面（因此存储在内容数据库中）。可用于将自定义功能（如报告页面或仪表板页面）传递给用户。网站页面可以动态创建并提供高度灵活性。但是，因为它们存储 在内容数据库中，Windows SharePoint Services 对这些页面应用严格的安全策略，不允许内嵌代码。另外，这些页面在无编译模式下运行。
应用程序页	存 储在 \12\Template\Layouts 文件夹中的实际 ASP.NET 页面。该文件夹通常由在 Web 服务器上托管的所有 Windows SharePoint Services 网站共享。应用程序页非常适用于创建针对 SharePoint 网站的其他管理功能。由于它们不是数据库的一部分，因此允许内嵌代码。
样式表和母版页	这两者一起定义了网站的外观，以及网站的所有页面使用的公用功能。
导航控件	基 于 ASP.NET 的导航控件，提供基于 ASP.NET 提供程序模型的体验。Windows SharePoint Services 提供了许多默认的基于 ASP.NET 的导航控件。使用 Windows SharePoint Services 提供面向大众 (Internet) 的网站时，通常需要自定义导航控件。
用户控件	ASP.NET 用户控件（.ascx 文件），可以将常用功能传递给 SharePoint 网站中的页面。Windows SharePoint Services 在 \12\Template\ControlTemplates 文件夹中提供了多个控件。例如，在母版页内创建其他自定义用户控件并使其可视化。用户控件可以将特定编辑体验提供给用户，如自定义信息管理策略或自定义字 段。

架构

架构是使用协作应用程序标记语言 (CAML) 的基于 XML 的解决方案。表 3 介绍了您可以通过使用架构驱动传递的功能。

表 3. 通过架构提供的功能的类型

功能 说明

网站定义	部署在 \12\Template\SiteTemplate 文件夹中的网站的自定义模板。自定义网站定义的核心文件是 Onet.xml，其中包含网站全局定义以及可能的配置。
功能	在 Windows SharePoint Services 3.0 中引入，采用模块化方法将自定义架构和功能传递到 SharePoint 网站。功能可以激活您构建和部署的内容。通过使用功能定义，可以提供许多先前提到的解决方案类型。您可以在 \12\Template\Features 文件夹中找到部署的功能定义的列表。
自定义列表	自定义列表和文档库的架构也通过基于 CAML 的文件进行定义（很多情况下是作为功能定义的一部分）。但是，它们也可以是自定义网站定义的一部分。
网站列和内容类型	可重用的打包内容定义的架构，可以在 SharePoint 容器（列表和文档库）中存储和管理这些内容。大多数情况下通过功能定义提供网站列和内容类型。
自定义字段定义	这些基于 CAML 的文件与包含隐藏代码的 .NET 程序集一起提供其他字段类型供用户选择，例如在文档库中创建自定义元数据时进行选择。

数据操作

在 SharePoint 网站中存储和管理的所有内容以及所有配置数据都保留在 SQL Server 数据库中，您无需与之直接交互。Windows SharePoint Services 和 MOSS 具有由大量 .NET 程序集提供的相当丰富的对象模型，其中 Microsoft.SharePoint.dll 和 Microsoft.Office.Server.dll 尤为重要。

仅当将应用程序部署到属于服务器场的计算机之一时，才可以访问服务器对象模型。如果访问 Windows SharePoint Services 的应用程序是远程部署的，请改为使用 Web 服务 API。

与 SharePoint 类直接交互的解决方案必须具有访问网站（协作网站或管理网站，取决于解决方案类型）的 SharePoint 上下文的权限。示例有已部署到运行 Windows SharePoint Services 的服务器的基于 Windows 的应用程序、在 Windows SharePoint Services 上下文中运行的 Web 部件、以自定义方式公开数据的自定义 Web 服务以及在 SharePoint 服务器上运行的 Windows 服务等。

Windows SharePoint Services 中有许多可用的 Web 服务，这些服务提供了大部分必需的数据操作。但是，当需要自定义功能时，您始终可以创建自定义 Web 服务，让 Windows SharePoint Services 承载它们并将其与内置 Web 服务集成。

还有基于 HTTP 的协议 — FrontPage Server Extensions 远程过程调用 (RPC) 协议供远程客户端用于处理在 Windows SharePoint Services 中的文档库中存储的文档。Microsoft Office system 客户端就是使用该协议的智能客户端的示例。

开发环境

开发人员可以使用两种环境构建 SharePoint 解决方案。您的选择受多种因素的影响，其中包括网络基础结构、授权、团队大小和要构建的解决方案类型。在本文中，我们建议您选择一种我们视为最佳实践的环境。

远程工作

在 我们介绍的设置中，开发人员在安装了 Microsoft Visual Studio 2005 的非服务器操作系统上以本地方式工作。他们首先构建解决方案，然后逐步完成将这些解决方案部署到运行 Windows SharePoint Services 3.0（还可能有 MOSS）的中央服务器的步骤。图 3 显示了该设置。

图 3. 用于远程工作的设置

根据解决方案的类型，必须将特定的 .NET 程序集（例如，Microsoft.SharePoint.dll）复制到本地开发环境。

按照此方式工作有很多好处。第一个重要好处是开发人员不必在其本地开发计算机上安装服务器软件。这会影响授权，还为已在其本地计算机上执行了大量开发任务的开发人员减轻了安装负担。第二个好处是您可以设置集中管理的源代码控制系统，并且管理员还可对备份进行集中管理。

但是，当开发人员使用此方式工作时，将遇到重重困难。首先，远程调试代码将是一项挑战。例如，构建开发人员在其中调试代码的 Web 部件时，需要考虑许多环境变量，如下所示：

• 在调试网站的解决方案时，开发人员需要在服务器上具有强有力的特权。

• 开发人员还会阻止正在处理同一网站的解决方案的其他所有开发人员。

• 每次必须进行测试时，开发人员必须将代码打包并完成部署服务器的步骤，才能在操作中看到其代码。这可能有好处，因为从一开始，开发人员就必须进行适当的打包，但当以此方式工作时，通常会不利于开展工作。

  注意：

  许多基于程序集的解决方案要求运行 Windows SharePoint Services 的服务器上具有 IISRESET，以激活更新的版本。

本地工作

或者，您可以配置开发环境，使得所有的 SharePoint 开发工作都可以在本地完成。图 4 显示了此设置。

图 4. 用于本地工作的设置

建议使用此配置，原因如下：

• 从长远来看，能够在本地构建、测试和调试解决方案有助于提高开发人员的工作效率。构建基于程序集的解决方案时，尤其如此。

• 测试解决方案并不会妨碍同事的工作。但是，在本地工作对开发人员的专业素质要求更高。例如，在本解决方案中，设置有效的备份和源代码控制系统将更具有挑战性。

• 本 地开发环境可以是在本机上安装了带有 Windows SharePoint Services 3.0 的 Windows Server 2003，也可以是安装了 MOSS。但是，如前所述，对于在同一台计算机上同时执行其他开发任务的开发人员而言，这可能会带来沉重的负担。如果您不希望执行本机安装，那么，选用配 置好的 Microsoft Virtual PC 开发环境不失为一个很好的选择，尽管这种方法需要更多的内存和硬盘空间。

Visual Studio 2005 Extensions for Windows SharePoint Services 3.0

Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 可以提高很多开发任务的生产率。它提供了下列内容：

• 项目模板，用于构建 Web 部件、工作组网站、空白网站定义和列表定义。

• 单项模板，用于将 Web 部件类、自定义字段控件和模块与列表定义和内容类型（两者均具有可选事件接收器）一起添加到现有项目。

• 一个名为 SharePoint Solution Generator 的外部 Windows 应用程序，它可以获得配置的工作组网站、对其进行反向工程，并为您提供汇集在 Visual Studio 2005 项目中的各个片断。

请 牢记，Visual Studio 2005 Extensions 用于在开发过程中为开发人员提供支持，包括整个的测试和调试阶段。在使用本文中的演练时，这些扩展使您可以将重点放在代码上，不必首先设置项目基础结构即 可开始编写代码，在 Windows SharePoint Services 解决方案中编译和打包代码，并可以毫不费力地将其部署到您的网站集合之一 — 准备进行测试和调试。

但是，您可以使用一些配置选项来更改打包和部署解决方案的默认方式。下文将介绍必须以手动方式控制、打包和部署解决方案的不同方案。

下面介绍一些演练，以展示可使用 Visual Studio Extensions for Windows SharePoint Services 3.0 执行的一些开发任务。

演练：构建 Web 部件项目

如 果您熟悉 Visual Studio Extensions for Windows SharePoint Services 3.0，也能够熟练使用它来构建 Web 部件，则您可能希望继续进行下一部分。对于不熟悉这些扩展的读者来说，这一简短的演练使用一个 Web 部件（用来显示有名的 Hello World 字符串）介绍了创建项目的不同步骤。（请不要担心！接下来会更令人兴奋。）

使用显示 Hello World 字符串的 Web 部件创建项目

1. 打开 Visual Studio 2005，然后创建一个新的 Web 部件项目，如图 5 中所示。

   图 5. 创建 Web 部件项目

   
   
   

   请注意，在解决方案资源管理器中，您引用了 Microsoft.SharePoint.dll 和 System.Web.dll。后一个引用至关重要，因为其中的 WebPart1.cs 文件包含一个从 ASP.NET 2.0 WebPart 类继承的类。这就是您在 Windows SharePoint Services 3.0 中构建的新“样式”的 Web 部件类。

2. 只需编写如下所示的简短代码即可输出一个小字符串作为 Web 部件的主体。最终代码如下所示。

   C#

   using System;
   using System.Runtime.InteropServices;
   using System.Web.UI;
   using System.Web.UI.WebControls.WebParts;
   using System.Xml.Serialization;
   
   using Microsoft.SharePoint;
   using Microsoft.SharePoint.WebControls;
   using Microsoft.SharePoint.WebPartPages;
   
   namespace MSDN
   {
       [Guid("28c3eefe-2c03-4791-9f69-4405c80e1d92")]
       public class HelloWorldWebPart : System.Web.UI.WebControls.WebParts.WebPart
       {
           protected override void Render(HtmlTextWriter writer)
           {
               writer.Write("Hello Readers!");
           }
       }
   }

3. 在测试 Web 部件之前，请执行下列配置任务。如图 6 所示，在解决方案资源管理器中打开项目的属性，然后单击 SharePoint 解决方案选项卡。

   下文会讲述功能和解决方案的概念，但此处简要说明涉及的 XML 文件的特定元素，如下所示：

   • 解决方案节点，带有解决方案的名称和 ID。

   • feature.xml 文件的节点，可以从此文件中更改要在 \12\Template\Features 路径下创建的文件夹的名称。另外，此节点还显示标题、说明和作用域（默认设置为网站集级别）。

   • 指令清单文件 (elements.xml) 的节点，可以从此处设置 Web 部件自身的标题和说明。

     注意：

     变暗的属性不能更改。例如，对于 Web 部件项目，无法更改 feature.xml 文件和注册事件处理程序。稍后，我将介绍此问题的解决方法。

   图 6. 项目属性中的“SharePoint 解决方案”选项卡

   
   
   

4. 在 Visual Studio 2005 中，按 F5 安装 SharePoint 解决方案，并且将其部署您的其中一个已扩展的 IIS Web 应用程序中。使用调试选项卡将其指定到要在其中将 Web 部件作为激活功能列出的 Visual Studio。

   本文稍后将详细介绍后台正在执行的操作。简而言之，代码会被打包到 SharePoint 解决方案中，添加到服务器场级别的解决方案存储区，并部署到网站集。此时，您应该能够将 Web 部件添加到目标站点的页面上，如图 7 所示。

   图 7. 使用 F5 构建和部署 Web 部件

   
   
   

演练：创建自定义字段类型

Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 也支持开发其他类型的 SharePoint 解决方案。例如，您可以创建一个空项目，然后添加单项模板。以下步骤用于创建简单的字段类型，并在 Windows SharePoint Services 开发环境中快速而轻松地部署和激活它。

创建、部署和激活简单字段类型

1. 打开 Visual Studio 2005，然后创一个新 SharePoint 项目。

   此时，基本未创建任何内容。当然！您选择的是一个空项目！但是，现在您可以添加一个基于字段控件模板的新项，如图 8 所示。我创建的是一个捕获、存储并生成项目引用编号的简单字段。（在强制创建三位数编号的过程中，少量验证逻辑被封装。）

   图 8. 添加字段控件项模板

   
   
   

2. 在此过程中，添加了两个类：一个用于自定义字段，另一个用于以自定义方式呈现捕获字段值的控件。添加的唯一代码段位于 ProjectReferenceNumberField 类中。在此类中，添加以下方法。

   C#

           public override string GetValidatedString(object value)
           {
               if (value.ToString().Length != 3)
               {
                   throw new SPFieldValidationException
                            ("Only 3 characters allowed!");
               }
               else
               {
                   return value.ToString();
               }
           }

3. 按 F5 之前，使用项目的属性配置使自定义字段类型可用的方法。此时，不存在 feature.xml 文件，但创建了带有前缀 fldtypes 的另一个 XML 文件，该文件位于 \12\TEMPLATE\XML 文件夹下。您可以设置 TypeDisplayName 和 TypeShortDescription 的值。此外，使用调试选项卡指定按 F5 时浏览器应导航到的站点（图 9）。

   图 9. 准备构建和部署自定义字段类型

   
   
   

4. 按 F5。图 10 显示了如何使新字段成为可能字段类型列表的一部分。图 11 显示了用于检查字段值长度并为用户返回错误消息的验证代码。

   图 10. 使用新字段类型创建列

   
   
   

   图 11. 自定义字段值长度的验证

   
   
   

演练：对工作组网站进行反向工程

下 一个示例演示了如何使用 SharePoint Solution Generator 通过 Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 对现有（可能是自定义的）SharePoint 工作组网站进行反向工程。演练为您展示了如何对 40 个模板（可从 MSDN 站点下载）中的一个进行反向工程。许多模板以 .stp 文件形式提供（使用浏览器中“另存为模板”命令的结果）。

注意：

您可以从 Windows SharePoint Services 3.0 应用程序模板下载这些模板。

在此演练中，我们为 SharePoint Solution Generator 提供了 Sports League 模板，并生成了一个包含站点定义的单个组件及所涉及的功能的 .NET 项目。

使用 SharePoint Solution Generator 对 SharePoint 工作组网站进行反向工程

1. 下载 Sports League 模板，安装此模板并将其上载到您的其中一个网站集的站点模板库中。

2. 创建基于此最新可用模板的站点。图 12 显示了这些操作的结果。

   图 12. 基于 Sports League 站点模板的站点

   
   
   

3. 开始使用 SharePoint Solution Generator 之前，请从该页中删除带有 Windows SharePoint Services 图像的 Web 部件。

4. 打开 SharePoint Solution Generator（图 13），单击站点定义，然后执行下一步。

   图 13. 开始使用 SharePoint Solution Generator

   
   
   

5. 键入要进行反向工程的站点 URL，或使用树视图导航到该站点。指定创建 Visual Studio 2005 项目的位置。

6. 单击开始按钮启动 Solution Generator。

7. 完成 Solution Generator 后，您可以打开 Visual Studio 2005 项目。图 14 显示了输出内容。

   图 14. Visual Studio 2005 中的站点定义

   
   
   

   该项目由许多部分组成，本文不对其进行一一论述。不过，您可以查看列表和库的架构定义以及站点定义本身。

8. 再次按 F5 可启用开发计算机上的所有功能。使用 SharePoint 解决方案选项卡，您可以配置表示站点每个部分的不同功能的许多详细信息以及站点定义本身。

详细了解 Windows SharePoint Services 解决方案

使 用 Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 的好处之一是开发工作的输出内容将打包到 SharePoint 解决方案中。这对希望尽快在其开发计算机上测试代码的开发人员而言非常有用，不过，请记住它在更改用于打包和部署解决方案的配置参数方面缺乏灵活性。

解决方案 是我们现在使用的官方术语，指将自定义 Windows SharePoint Services 开发工作传递到前端 Web 服务器（也可能传递到服务器场中的应用程序服务器）的分发包。图 15 显示了可打包到 SharePoint 解决方案中的各种组件的概述。这些组件包括：

• 用于打包推动解决方案的代码的 .NET 程序集。

• 部署文件，如资源文件、图像或其他帮助文件。

• 许多解决方案，包括为站点、列表、库、字段、内容类型等提供新模板和定义。这些定义都以基于 CAML 的 XML 文件形式显示。

• 最后，还包括必须在前端 Web 服务器级别执行的配置（例如，在 web.config 文件中注册 Web 部件）。

图 15. SharePoint 解决方案分析

除 此之外，还必须包括一个非常重要的文件 — 指令清单文件，用于在解决方案部署进程中协助 Windows SharePoint Services。指令清单文件是一个 XML 文件，稍后我将进行详细描述。简而言之，指令清单文件包含解决方案中所有资产的列表，以及这些资产的目标位置及其必须进行的各种配置。

指令清单文件分析

指令清单文件可能包含什么内容？很多内容 — 后面是每种项类型的简短说明。在开始之前，您会注意到指令清单文件的架构定义包含在 WSS 系统文件夹的 Wss.xsd 文件中。

注意：

WSS 系统文件夹位于路径 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12 下。

所以您可能要将其添加到 Visual Studio 2005 环境以获取 IntelliSense 支持。图 16 显示了指令清单文件的主要 XML 元素。

图 16. 解决方案指令清单文件中的主要 XML 元素

解决方案元素

解决方案元素是指令清单文件的根元素。SolutionId 属性是该文件的重要元素。SolutionId 用于标识解决方案存储区（配置数据库的一部分，本文稍后将进行讨论）中的解决方案。使用 GUID 标识解决方案。

Xml

<Solution SolutionId="1de3b0fc-78e9-4fe6-ae63-51ea50109982" xmlns="http://schemas.microsoft.com/sharepoint/" >
</Solution>

DeploymentServerType 和 ResetWebServer 是可选属性。DeploymentServerType 有两种可能值：ApplicationServer 或 WebFrontEnd。通常，大部分解决方案以服务器场中的前端 Web 服务器为目标。将应用程序服务器（例如，索引服务器、运行 Excel Services 的服务器、文档转换服务器等）定为目标的解决方案示例为自定义配置或其他自定义转换器。IISReset 属性可用于将解决方案部署到特定 IIS Web 应用程序时，启动 Internet 信息服务 (IIS) 重置。

FeatureManifest 元素

功能在许多 Windows SharePoint 解决方案中发挥着重要作用，因为它们代表解决方案（如字段类型、Web 部件、工作流等）的各部分。您必须使用 FeatureManifest 元素表示解决方案中包含的每种功能。以下代码示例包含在 SharePoint 站点发布 Web 部件的功能。

Xml

<Solution SolutionId="dda6427b-b880-46c0-a428-10c4bac0ce91" xmlns="http://schemas.microsoft.com/sharepoint/" >
  <FeatureManifests>
    <FeatureManifest Location="HelloWorldWebPart_28c3eefe-2c03-4791-9f69-4405c80e1d92\feature.xml" />
  </FeatureManifests>
  …
</Solution>

将解决方案部署到前端 Web 服务器时，所有与功能相关的文件都被复制到此处指定的位置。

Assembly 元素

大部分 SharePoint 解决方案都涉及一个或多个 .NET 程序集。Assembly 元素在指令清单文件中用于使 DLL 在目标服务器上可用。下面是一个示例。

Xml

<Solution SolutionId="dda6427b-b880-46c0-a428-10c4bac0ce91" xmlns="http://schemas.microsoft.com/sharepoint/" >
…
  <Assemblies>
    <Assembly Location="HelloWorldWebPart.dll" DeploymentTarget="GlobalAssemblyCache" >
      <SafeControls>
        <SafeControl Assembly="HelloWorldWebPart, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5" Namespace="MSDN" TypeName="HelloWorldWebPart" Safe="True" />
      </SafeControls>
    </Assembly>
  </Assemblies>
</Solution>

Assembly 元素的第一个属性是 Location，该属性将 DLL 的相对路径存储在解决方案文件中。下一个是 DeploymentTarget 属性，它有两个可能值：GlobalAssemblyCache 或 WebApplication。GlobalAssemblyCache 表示应将程序集部署到全局程序集缓存中；WebApplication 指示 Windows SharePoint Services 将程序集拖动到 IIS Web 应用程序的专用应用程序文件夹中。正如本文后面所论述，WebApplication 表示所使用的解决方案取决于管理员在与 IIS Web 应用程序相关联的 web.config 文件中设置的信任级别。在全局程序集缓存（完全受信任的位置）中部署程序集，意味着作为开发人员您不必担心设置此信任级别。

解决方案中的 Web 部件必须作为安全控件在 web.config 文件中注册。Assembly 元素可以包含一个或多个 SafeControl 元素（在 SafeControls 元素中组合在一起）。每个 SafeControl 元素描述了必须在 web.config 文件中进行的配置。

Assembly 元素的另一可能的子元素集是 ClassResource 元素（在 ClassResources 元素中组合在一起）。每个子元素代表部署的程序集可能需要的一种资源。例如，资源文件、XML 文件或图片。