原文地址：http://msdn.microsoft.com/zh-cn/library/bb530302.aspx
摘要：了解针对 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 技术进行开发简介
许多开发人员急于利用 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 部件创建项目
-
打开 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 部件类。
-
只需编写如下所示的简短代码即可输出一个小字符串作为 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!"); } } } -
在测试 Web 部件之前，请执行下列配置任务。如图 6 所示，在解决方案资源管理器中打开项目的属性，然后单击 SharePoint 解决方案选项卡。
下文会讲述功能和解决方案的概念，但此处简要说明涉及的 XML 文件的特定元素，如下所示：
-
解决方案节点，带有解决方案的名称和 ID。
-
feature.xml 文件的节点，可以从此文件中更改要在 \12\Template\Features 路径下创建的文件夹的名称。另外，此节点还显示标题、说明和作用域（默认设置为网站集级别）。
-
指令清单文件 (elements.xml) 的节点，可以从此处设置 Web 部件自身的标题和说明。
注意：变暗的属性不能更改。例如，对于 Web 部件项目，无法更改 feature.xml 文件和注册事件处理程序。稍后，我将介绍此问题的解决方法。
图 6. 项目属性中的“SharePoint 解决方案”选项卡
-
-
在 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 开发环境中快速而轻松地部署和激活它。
创建、部署和激活简单字段类型
-
打开 Visual Studio 2005，然后创一个新 SharePoint 项目。
此时，基本未创建任何内容。当然！您选择的是一个空项目！但是，现在您可以添加一个基于字段控件模板的新项，如图 8 所示。我创建的是一个捕获、存储并生成项目引用编号的简单字段。（在强制创建三位数编号的过程中，少量验证逻辑被封装。）
图 8. 添加字段控件项模板
-
在此过程中，添加了两个类：一个用于自定义字段，另一个用于以自定义方式呈现捕获字段值的控件。添加的唯一代码段位于 ProjectReferenceNumberField 类中。在此类中，添加以下方法。
C#
public override string GetValidatedString(object value) { if (value.ToString().Length != 3) { throw new SPFieldValidationException ("Only 3 characters allowed!"); } else { return value.ToString(); } } -
按 F5 之前，使用项目的属性配置使自定义字段类型可用的方法。此时，不存在 feature.xml 文件，但创建了带有前缀 fldtypes 的另一个 XML 文件，该文件位于 \12\TEMPLATE\XML 文件夹下。您可以设置 TypeDisplayName 和 TypeShortDescription 的值。此外，使用调试选项卡指定按 F5 时浏览器应导航到的站点（图 9）。
图 9. 准备构建和部署自定义字段类型
-
按 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 工作组网站进行反向工程
-
下载 Sports League 模板，安装此模板并将其上载到您的其中一个网站集的站点模板库中。
-
创建基于此最新可用模板的站点。图 12 显示了这些操作的结果。
图 12. 基于 Sports League 站点模板的站点
-
开始使用 SharePoint Solution Generator 之前，请从该页中删除带有 Windows SharePoint Services 图像的 Web 部件。
-
打开 SharePoint Solution Generator（图 13），单击站点定义，然后执行下一步。
图 13. 开始使用 SharePoint Solution Generator
-
键入要进行反向工程的站点 URL，或使用树视图导航到该站点。指定创建 Visual Studio 2005 项目的位置。
-
单击开始按钮启动 Solution Generator。
-
完成 Solution Generator 后，您可以打开 Visual Studio 2005 项目。图 14 显示了输出内容。
图 14. Visual Studio 2005 中的站点定义
该项目由许多部分组成，本文不对其进行一一论述。不过，您可以查看列表和库的架构定义以及站点定义本身。
-
再次按 F5 可启用开发计算机上的所有功能。使用 SharePoint 解决方案选项卡，您可以配置表示站点每个部分的不同功能的许多详细信息以及站点定义本身。
部署 Windows SharePoint Services 解决方案
对前端 Web 服务器或应用程序服务器部署 Windows SharePoint Services 解决方案是分两个阶段执行的，如图 19 所示。
图 19. 部署 SharePoint 解决方案的步骤
将解决方案添加到解决方案存储区
必须将 SharePoint 解决方案添加到服务器场中可用的解决方案存储区。解决方案存储区是配置数据库的一部分，其中存储了多种 .wsp 文件。可通过 Stsadm.exe 命令行实用程序或使用编程方法将解决方案添加到存储区。
使用 Stsadm.exe
您可通过指定 .wsp 文件的相对路径借助 addsolution 操作调用 Stsadm.exe。下面是一个示例。
stsadm –o addsolution –filename mysolution.wsp
注意：
如果您要本地化该解决方案，还可以使用第三个参数：lcid。
使用 Windows SharePoint Services 3.0 对象模型
在另外一种方法中，您可以创建一个与由 Windows SharePoint Services 公开的对象模型通信的 .NET Framework 应用程序。可使用下面的一行代码将 SharePoint 解决方案添加到解决方案存储区。
C#
SPSolution solution = SPFarm.Local.Solutions.Add(@"C:\Package\MySol.wsp");
Microsoft.SharePoint.Administration 命名空间中的 SPFarm 类使您可以连接到服务器场（本地创建的服务器场或您远程加入到的服务器场）。只要 SPSolutionCollection 对象是 SPSolution 类的实例或 SharePoint 解决方案文件的路径，就可以通过调用 Add 方法使用新的解决方案填充该对象。会返回一个 SPSolution 实例。在此级别会公开大量属性和方法。
部署解决方案
下一步是将解决方案实际部署到一台或多台支持 Windows SharePoint Services 的 Web 服务器（前端 Web 服务器或应用程序服务器）。可通过三种方式部署解决方案：
-
使用 Stsadm.exe
-
使用 Windows SharePoint Services 3.0 对象模型
-
使用 SharePoint 管理中心网站
以下各节分别介绍这三种部署方法。
使用 Stsadm.exe
Stsadm.exe 有一个 deploysolution 选项，您可通过命令提示符使用该选项部署解决方案。解决方案存储区中的解决方案的名称是参数之一，您的目标网站集的 URL 也是参数之一。以下是一个示例。
stsadm –o deploysolution –name mysolution.wsp
–url http://moss.litwareinc.com
除了以一个网站集为目标外，您还可以选择将自己的解决方案推送到服务器场中每一个可用的网站集。为此，您可以使用 allcontenturls 参数，如下所示。
stsadm –o deploysolution –name mysolution.wsp –allcontenturls
默认情况下，将立即部署解决方案，但您也可使用 time 参数计划部署。
allowgacdeployment 和 allowcaspolicies 参数也非常重要，稍后会对它们详加论述。简言之，默认情况下 allowgacdeployment 为 true，表示支持 Windows SharePoint Services 在全局程序集缓存中部署程序集。allowcaspolicies 参数支持创建自定义代码访问安全 (CAS) 策略文件，并在目标网站集的 Web.config 文件中激活该策略文件。
通过 Windows SharePoint Services 3.0 对象模型部署解决方案
在 SPSolution 实例级别，可以使用两种方法以编程方式部署解决方案：Deploy 和 DeployLocal。这两种方法均可接受 SPWebApplication 对象的集合，这些对象由希望作为部署目标的 Internet 信息服务 (IIS) Web 应用程序填充。可按如下所示填充该集合。
C#
Collection<SPWebApplication> webapps = new Collection<SPWebApplication>();
SPWebApplication webapp =
SPWebApplication.Lookup(new Uri("http://wss.litwareinc.com"));
webapps.Add(webapp);
这两种方法还都允许将包含在 Web 部件解决方案中的程序集部署到全局程序集缓存。两种方法的不同之处在于，您可以使用 DateTime 参数（该参数存储了您希望部署解决方案的确切时间）调用 Deploy，如图 20 所示。
图 20. 为部署计划的 SharePoint 解决方案
下面是一个使用 Deploy 方法的代码示例。
C#
solution.Deploy(DateTime.Now.AddMinutes(5), true, webapps, true);
下面是一个调用 DeployLocal 方法的示例。
C#
solution.DeployLocal(true, webapps, true);
通过 SharePoint 管理中心网站部署解决方案
管理员还可以导航到管理中心的操作页，使用解决方案管理立即或在将来的指定时间将 Windows SharePoint Services 解决方案部署到 IIS Web 应用程序。
当作为解决方案一部分的指令清单文件要求将程序集部署到全局程序集缓存中时，管理员会收到一条警告。
手动打包 Windows SharePoint Services 解决方案
Windows SharePoint Services 解决方案的开发人员经常采用手动方式创建 SharePoint 解决方案包。以下是需要手动打包的情形：
-
在专用应用程序文件夹而不是全局程序集缓存中部署 .NET 程序集。
-
向解决方案添加在部署期间必须应用的代码访问安全权限。
-
使用不同于 Feature 文件夹默认使用的名称。
-
本地化 Windows SharePoint Services 解决方案。
-
将 Feature 事件处理程序与特定类型的 Windows SharePoint Services 解决方案（如 Web 部件解决方案）相关联。
-
向解决方案包添加资源（XML 文件、图片等）。
要手动创建解决方案文件，需要执行以下基本步骤：
-
将所有单个解决方案文件收集到某个文件夹中。如何执行此步骤没有具体的指导说明，但最佳实践是将不同类型的解决方案文件分别放到它们各自的子文件夹中。
-
创建一个 .ddf 文件（Diamond Directive File 的缩写），该文件定义了 Windows SharePoint Services 解决方案文件的结构。此文件中包含了决定输出 .wsp 文件的各解决方案文件的列表。
-
执行命令行实用程序 MakeCab.exe，将 .ddf 文件作为输入，.wsp 文件作为输出。
下面的简短演练演示了上述所有步骤。
演练：生成和部署自定义 Web 部件解决方案包
Windows SharePoint Services 3.0 为开发人员提供了在安装、激活、停用或卸载 Feature 时执行自定义代码的选项。例如，一个依赖特定任务列表的 Web 部件。当 Web 部件 Feature 被激活后，自定义代码可以检查此任务列表是否属于站点内的列表。如果不属于，该代码将创建该列表，然后在 Feature 被停用时删除该列表。自定义代码被封装在称为 Feature Receiver Assembly 的 .NET 程序集中。
此演练假设您已像在 Windows SharePoint Services 3.0 中使用代码的开发工具和技术（第 1 部分，共 2 部分）中那样创建了一个 Web 部件项目。当安装、激活、停用或卸载 Web 部件 Feature 时，Windows SharePoint Services 触发异步事件。通过创建一个继承自抽象 Microsoft.SharePoint.SPFeatureReceiver 类的 .NET 类，可以在自定义 .NET 程序集中处理这些事件。以下是示例中的类和要实现的四个成员。
C#
using System;
using System.Diagnostics;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;
namespace MSDN.Samples
{
public class MSDNTaskListEventHandler: SPFeatureReceiver
{
public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
SPSite sitecollection = (SPSite)properties.Feature.Parent;
SPWeb web = sitecollection.RootWeb;
try
{
// -- 检查是否存在列表。
SPList list = web.Lists["MSDN Tasks"];
}
catch
{
// -- 如果不存在，则创建列表。
web.Lists.Add("MSDN Tasks", "A custom list", SPListTemplateType.Tasks);
}
}
public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
SPSite sitecollection = (SPSite)properties.Feature.Parent;
SPWeb web = sitecollection.RootWeb;
try
{
// -- 检查列表是否位于该位置，如果是，则删除。
SPList list = web.Lists["MSDN Tasks"];
web.Lists.Delete(list.ID);
}
catch (Exception ex)
{
}
}
public override void FeatureInstalled(SPFeatureReceiverProperties properties)
{
}
public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
{
}
}
}
编码工作产生两个程序集。一个程序集包含发送 Web 部件的编码。另一个程序集包含前面的代码。编写时，Visual Studio Extensions for Windows SharePoint Services 3.0 不允许将事件处理程序连接到 Web 部件 Feature 定义文件。另外，必须在专用应用程序文件夹而非全局程序集缓存中部署 Web 部件程序集。因此，您必须手动创建解决方案包。
注意：
在下面的步骤中，可以调整代表解决方案组件的不同文件的组织方式，使其适合您自己的偏好，这种组织方式可以作为 Visual Studio 2005 解决方案的一部分。
创建包含两个子文件夹的文件夹来收集所有解决方案组件。第一个子文件夹用于存储程序集（在本文中称为 Assemblies），第二个文件夹用于存储定义 Feature 的不同 XML 文件（在本文中称为 Features）。将 Web 部件程序集和事件处理程序集复制到 Assemblies 文件夹中。
在 Features 文件夹下创建一个子文件夹，用于容纳 SharePoint 解决方案中必须包含的每个 Feature。此演练中只有一个 Feature。假设它被称为 MSDNTaskCreator；Features 文件夹包含一个使用该名称的子文件夹。在此文件夹的根目录下，添加一个包含以下 XML 的 .xml 文件。
Xml
<Feature Title="MSDNTaskCreator"
Id="55312295-a323-4333-b875-1bbe8ef7fd04"
Description="Small Web Part creating a custom task item"
Version="1.0.0.0" Scope="Site" Hidden="FALSE"
ReceiverAssembly="MSDNFeatureEventhandlers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5e5a470a5445a8f1"
ReceiverClass="MSDN.Samples.MSDNTaskListEventHandler"
DefaultResourceFile="core" xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
<ElementManifest Location="elementManifest.xml" />
<ElementFile Location="MSDNTaskCreator.webpart" />
</ElementManifests>
</Feature>
此 XML 与使用 Visual Studio Extensions for Windows SharePoint Services 3.0 生成的 XML 有何不同呢？feature.xml 文件添加了另外两个属性：
-
ReceiverAssembly 属性包含 .NET 程序集（其中包含事件处理程序代码）的完整强名称。
-
ReceiverClass 属性存储了该程序集内的类的完整名称。
必须在根文件夹中创建指令清单文件。该文件与由 Visual Studio Extensions for Windows SharePoint Services 3.0 生成的文件不同。以下是文件内容。
Xml
<Solution SolutionId="d63d0395-96a4-449e-83ce-5f7239bbd3ad" xmlns="http://schemas.microsoft.com/sharepoint/" >
<FeatureManifests>
<FeatureManifest Location="MSDNTaskCreator\feature.xml" />
</FeatureManifests>
<Assemblies>
<Assembly Location="MSDNTaskCreator.dll" DeploymentTarget="WebApplication" >
<SafeControls>
<SafeControl Assembly="MSDNTaskCreator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5" Namespace="MSDN.Samples" TypeName="MSDNTaskCreator" Safe="True" />
</SafeControls>
</Assembly>
<Assembly Location="MSDNFeatureEventHandlers.dll" DeploymentTarget="GlobalAssemblyCache" />
</Assemblies>
</Solution>
注意，Feature 的名称不再包括 GUID。第一个程序集元素包含一个名为 DeploymentTarget 的属性，其值为 WebApplication 而不是 GlobalAssemblyCache。第二个程序集元素具有 .NET 程序集的定义，包含要在全局程序集缓存中部署的事件处理程序代码。
现在我们即可创建 .ddf 文件，在此示例中名为 .wsp_structure.ddf。可直接在 DeploymentFiles 文件夹中创建该文件。首先，添加以下标题信息。
; ; *** 用于生成 SharePoint 解决方案的 .ddf 文件。 ; .OPTION EXPLICIT ; Generate errors .Set CabinetNameTemplate=MSDNTaskCreatorWebPart.wsp .set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory .Set CompressionType=MSZIP;** 将所有文件压缩到压缩文件中 .Set UniqueFiles="ON" .Set Cabinet=on .Set DiskDirectory1=Package
标题包含两个动态特性相当明显的部分：
-
CabinetNameTemplate 被设为 SharePoint 解决方案文件的名称 (MSDNTaskCreatorWebPart.wsp)。
-
DiskDirectory1 被设为 Package。这是用于容纳生成的 .wsp 文件的目录。
.ddf 文件的第二部分定义了包的结构。
; *** 指令清单文件 manifest.xml manifest.xml ; *** 功能文件 Features\MSDNTaskCreator\feature.xml MSDNTaskCreator\feature.xml Features\MSDNTaskCreator\elementManifest.xml MSDNTaskCreator\elementManifest.xml Features\MSDNTaskCreator\MSDNTaskCreator.webpart MSDNTaskCreator\MSDNTaskCreator.webpart ; *** 程序集 Assemblies\MSDNTaskCreator.dll MSDNTaskCreator.dll Assemblies\MSDNFeatureEventhandlers.dll MSDNFeatureEventhandlers.dll
.ddf 文件是 MakeCab.exe 工具的输入，该工具可在安装 Microsoft Cabinet SDK (C:\Program Files\Microsoft Cabinet SDK) 后获得，它也是 Smart Devices SDK (C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\SDKTools) 的一部分。
注意：
可以从 Internet Client SDK:Microsoft Cabinet SDK 下载 Microsoft Cabinet SDK。
为了方便打包和部署，可创建一个批处理文件，其内容如下。
set MakeCabTool=c:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\SDKTools\makecab.exe set SPAdminTool=%CommonProgramFiles%\Microsoft Shared\web server extensions\12\BIN\stsadm.exe "%MakeCabTool%" /f wsp_structure.ddf "%SPAdminTool%" -o addsolution -filename package\ MSDNTaskCreatorWebPart.wsp "%SPAdminTool%" -o deploysolution -name MSDNTaskCreatorWebPart.wsp -immediate -allowGACDeployment -url http://moss.litwareinc.com
前两行设置 Makecab 和 Stsadm 命令行工具的路径。接下来的一行用于创建解决方案包。
makecab.exe /f wsp_structure.ddf
执行后，MSDNTaskCreatorWebPart.wsp 会出现在 Package 文件夹中。下一行通过执行以下命令将 MSDNTaskCreatorWebPart.wsp 添加到服务器场中的解决方案存储区中。
stsadm.exe -o addsolution -filename Package\MSDNTaskCreatorWebPart.wsp
批处理文件的最后一行是将解决方案部署到您的一个网站集。可使用管理中心的操作选项卡下的“解决方案管理”页，也可以再次打开命令提示符窗口执行以下命令行。
stsadm.exe -o deploysolution -name MSDNTaskCreatorWebPart.wsp -local -allowGACDeployment -url http://moss.litwareinc.com
Web Part Feature 已安装但未激活。要激活该 Feature，请打开网站集功能页，然后单击激活按钮。由于触发 FeatureActivated 事件时会执行相应的代码，此时会创建一个 MSDN Task 列表。停用此功能时会将此任务列表从网站集的根网站中删除。
代码访问安全和 Web 部件解决方案
在许多封装的环境中，管理员不允许自定义代码组件具有完全信任。管理员可能会选择将解决方案部署到 Web 应用程序的 \bin 文件夹，该文件夹的权限必须明确指定。让我们看看相关的步骤。
我们可以用一个小的 Web 部件来演示所有这一切，该 Web 部件连接到一个返回指定城市的天气信息的 Web 服务。如果使用 Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 创建和部署此 Web 部件，则 .NET 程序集会被部署在全局程序集缓存中。您无法在开发计算机上干预此过程来以不同方式配置解决方案的生成过程和部署。由于部署是在全局程序集缓存中，因此 Web 部件可获得完全信任，连接到 Web 服务时没有任何安全问题。
这种情形适用于管理员允许您将 Web 部件程序集部署在全局程序集缓存中。但是，Web 部件程序集经常最终出现在 IIS Web 应用程序的专用 \bin 文件夹下。作为 Web 部件开发人员，需要依赖管理员在 web.config 文件中设置的信任级别。最后，对于执行与我们的天气 Web 部件功能相似的 Web 部件，您会遇到安全问题，如下面的演练中所述。
演练：代码访问安全和 Web 部件解决方案
假设您有一个返回某城市天气信息的小的 Web 服务，有一个 Web 部件引用这些信息，如图 21 所示。（您可以使用任意类型的 Web 服务设计一个示例。）
图 21. 引用天气 Web 服务的 Web 部件
要在 IIS Web 应用程序的专用应用程序文件夹而不是在全局程序集缓存（如果使用 Visual Studio 2005 Extensions for Windows SharePoint Services 3.0，则此为默认位置）中部署 Web 部件，可以在指令清单文件中进行更改来强制进行此设置。您可以将 Assembly 元素级别的 DeploymentTarget 属性设为 WebApplication 而不是 GlobalAssemblyCache，如以下示例中所示。
Xml
<Solution SolutionId="1de3b0fc-78e9-4fe6-ae63-51ea50109982" xmlns="http://schemas.microsoft.com/sharepoint/" >
<FeatureManifests>
<FeatureManifest Location="WeatherWebPart\feature.xml" />
</FeatureManifests>
<Assemblies>
<Assembly Location="WeatherWebPart.dll" DeploymentTarget="WebApplication" >
<SafeControls>
<SafeControl Assembly="WeatherWebPart, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5" Namespace="WeatherWebPart" TypeName="WeatherWebPart" Safe="True" />
</SafeControls>
</Assembly>
</Assemblies>
</Solution>
接下来，您必须手动创建 Windows SharePoint Services 解决方案。下面的 .ddf 文件显示了如何对组成 Web 部件解决方案的不同组件打包。
.OPTION EXPLICIT .Set CabinetNameTemplate=WeatherWebPart.wsp .set DiskDirectoryTemplate=CDROM ; 将所有压缩文件置于单独的目录下 .Set CompressionType=MSZIP ;** 将所有文件压缩到压缩文件中 .Set UniqueFiles="OFF" .Set Cabinet=on .Set DiskDirectory1=Package manifest.xml manifest.xml assemblies\WeatherWebPart.dll WeatherWebPart.dll Features\WeatherWebPart\feature.xml WeatherWebPart\feature.xml Features\WeatherWebPart\elementManifest.xml WeatherWebPart\elementManifest.xml Features\WeatherWebPart\WeatherWebPart.webpart WeatherWebPart\WeatherWebPart.webpart
只需调用 Makecab.exe 并将 .ddf 文件作为输入，即可生成 Windows SharePoint Services 解决方案。
makecab.exe /f WeatherWebPart.ddf
通过在命令提示符窗口执行以下命令，可以将该解决方案添加到解决方案存储区。
stsadm.exe -o addsolution -filename package\weatherwebpart.wsp
现在，导航到管理中心的解决方案管理页。您可以在该页面上部署解决方案。请注意，由于指令清单文件不要求将程序集部署到全局程序集缓存中，所以不会出现警告。继续执行操作，将解决方案部署到您的 IIS Web 应用程序之一。最好在与 IIS Web 应用程序关联的物理文件夹（默认情况下，位于 Inetpub\wwwroot\wss\VirtualDirectories\IIS Web 应用程序名 下）中验证程序集在 \bin 文件夹中可用。
假设 web.config 文件的信任级别未设置为 Full，则在您尝试运行天气 Web 部件时会出现异常（如图 22 所示）。
图 22. 在专用应用程序文件夹中部署的天气 Web 部件
在专用应用程序文件夹中部署的天气 Web 部件会导致意外问题。不过，该错误是意料之中的。打开 Windows 事件查看器（位于管理工具中），可以找到错误的完整详细信息：“请求 ‘System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ 类型的权限失败。”
换句话说，未授予您的 Web 部件与 Web 服务通信的权限。如何解决这一问题呢？一种方法是在 web.config 文件中将信任级别提升为完全，但这样做是有风险的。提升信任级别后，所有私人部署的程序集都会获得与在全局程序集缓存中部署的程序集相同的基本权限。更佳的解决方案是请求在 SharePoint 页面正确运行 Web 部件所需的权限，并在指令清单文件中包括该命令。部署该解决方案的管理员将收到一个通知，该通知表明获取权限的特定请求正在等待处理。管理员可以决定是否可以授予这些权限。继续进行操作时，会为当前处于激活状态的策略文件创建副本，并添加为 Web 部件请求的权限。此新的策略文件将成为在 web.config 文件中激活的文件。现在，我们可以对上述所有步骤进行更详细的考查。
已经有一条信息可供使用了。您具有所请求权限的完整详细信息（前面讨论过）。另一条信息是您使用的程序集的完整公钥 Blob。要检索此信息，请打开命令提示符窗口并执行以下命令。
Secutil.exe –hex –s WeatherWebPart.dll > keyblob.txt
执行后会得到一个文本文件，其中包含存在问题的程序集的完整公钥。所用的工具是 secutil.exe，此工具是 .NET Framework SDK 的一部分。
接下来，打开指令清单文件，添加以下 CodeAccessSecurity 元素（最好添加在 FeatureManifests 元素和 Assemblies 元素之间）。
Xml
<CodeAccessSecurity>
<PolicyItem>
<PermissionSet class="NamedPermissionSet" version="1"
Description="My webpart's permission set">
<IPermission class="AspNetHostingPermission" version="1"
Level="Minimal"/>
<IPermission class="SecurityPermission" version="1"
Flags="Execution" />
<IPermission version="1" Unrestricted="True"
class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<IPermission class="System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Unrestricted="True" version="1"> <ConnectAccess> <URI uri="$OriginHost$"/> <URI uri="http://moss:95/webservices/.*"/> </ConnectAccess> </IPermission>
</PermissionSet>
<Assemblies>
<Assembly Name="WeatherwebPart" Version="1.0.0.0" PublicKeyBlob="0x00240000048000009400000006020000002400005253413100040000010001000DAF8ED8D945CD2ABB2EE7953A6039B791A725F11B4588AC6D70B3E0648F955E9ED4C3C43CB044B8B0E8A6FF4D4FFBE9E3B9297D45F688A7264534E12414E17539305207EC961DA94DF294E7722CCD9BDBFC95A896E996F57156705D281EC39280BD604E87724556AF5807D146963F19F5B43DB69E1F22695463153A553260D2" />
</Assemblies>
</PolicyItem>
</CodeAccessSecurity>
在上面的代码中，IPermission 和 Assembly 元素区域对于检查而言很重要。首先，IPermission 元素请求与 Web 服务（假设此 Web 服务承载于 http://moss:95 IIS Web Application 之上）进行通信所需的权限。其次，Assembly 元素包含了存在问题的程序集的详细信息：名称、版本和必须从通过 secutil.exe 实用程序生成的 keyblob.txt 文件中检索的 Blob。
将这些更改应用于指令清单文件时，必须重新生成 Windows SharePoint Services 解决方案，并将其重新添加到解决方案存储区中。部署解决方案时，您会注意到页面底部会出现一条警告（请参见图 23），表明该解决方案包含代码访问安全策略，如果继续部署该解决方案，此安全策略就会生效。如果管理员并未看到此类问题，则可继续操作，然后 Web 部件就可以使用了。
图 23. 带有代码访问安全策略的 Web 部件解决方案
如果您正确按上述步骤进行了操作，天气 Web 部件会像以前一样再次工作。但是在后台，您会注意到在 web.config 文件的 securityPolicy 元素中出现了一个新条目，如下所示。
Xml
<securityPolicy>
<trustLevel name="WSS_Medium" policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\wss_mediumtrust.config" />
<trustLevel name="WSS_Minimal" policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\wss_minimaltrust.config" />
<trustLevel name="WSS_Custom" policyFile="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\config\wss_custom_wss_minimaltrust.config" />
</securityPolicy>
新的级别 — WSS_Custom — 现在是 web.config 文件中的活动信任级别。
管理解决方案
Windows SharePoint Services 3.0 也提供对管理 SharePoint 解决方案的支持。您可以通过多种方法收回解决方案、删除解决方案存储区中的解决方案和升级解决方案。
收回解决方案
当您收回 SharePoint 解决方案时，Windows SharePoint Services 会将所有解决方案组件从其部署位置进行物理删除。可以通过以下三种方法收回解决方案：
-
使用 Stsadm.exe
-
使用管理中心
-
使用 Windows SharePoint Services 3.0 对象模型
以下各节将对这些方法加以介绍。
使用 Stsadm.exe
名为 retractsolution 的选项会接受多个参数。解决方案的 name 是必不可少的参数。另外，您可以为特定 IIS Web 应用程序和网站集指定 URL，或通过 allcontenturls 参数将解决方案从其所有部署位置删除。time 参数可以计划对作业定义的收回。当您希望直接执行操作时，可使用 immediate 参数。
以下是用于收回解决方案的典型命令。
stsadm.exe –o retractsolution –name hellowebpart.wsp -immediate
使用管理中心
解决方案在解决方案存储区中可用后，您可以通过管理中心的解决方案管理页对其进行访问。您可以从该页开始收回解决方案的过程，如图 24 所示。
图 24. 从 IIS Web 应用程序收回 Web 部件
使用 Windows SharePoint Services 3.0 对象模型
收回解决方案的最后一种方法是通过 Windows SharePoint Services 3.0 对象模型。SPSolution 类公开了 Retract 和 RetractLocal 方法。可以使用 Retract 计划解决方案的回收。上述两种方法都提供了从所有或特定 SPWebApplication 对象集收回解决方案的选项。以下代码示例从在本地计算机上可用的所有 IIS Web 应用程序收回 Web 部件解决方案。
C#
SPSolution solution = SPFarm.Local.Solutions["hellowebpart.wsp"]; solution.RetractLocal();
收回 Web 部件解决方案
您可以使用上面提到的任一方式收回交付 Web 部件的解决方案。但是，应当注意，收回 Web 部件不会从 Web 部件库删除 .webpart 条目。因此，Web 部件将会保留在添加 Web 部件对话框中显示，用户仍然可以看到。但是，当用户将 Web 部件添加到某个页面时，会显示错误，因为 Web 部件已不再作为安全控件进行注册，并且程序集已从本地 bin 文件夹或全局程序集缓存中删除。还应注意，收回 Web 部件解决方案会导致现有 Web 部件实例停止工作，并在 SharePoint 页中显示一条错误。要解决此问题，您可以停用对从 Web 部件库删除 .webpart 文件的调用。
收回基于架构的解决方案
收回基于架构的解决方案（如自定义列表定义）时必须小心。可以存在许多实例，您可能并不希望破坏这些实例。因此，存在这些类型的解决方案实例时，最佳实践是使 Feature 对用户不可见，而不是收回解决方案。本文后面有关升级解决方案一节的小型演练展示了不同的步骤。
删除 Windows SharePoint Services 解决方案
可从解决方案存储区中删除已不再部署的 Windows SharePoint Services 解决方案。可通过三种方式执行此删除：
-
使用 Stsadm.exe
-
使用管理中心
-
使用 Windows SharePoint Services 3.0 对象模型
以下各节介绍了这些方法。
使用 Stsadm.exe
管理员现在可以启动命令行实用程序 Stsadm.exe，然后执行 deletesolution 选项。name 参数是解决方案的名称，是必不可少的。使用以下命令可删除解决方案。
stsadm.exe –o deletesolution –name hellowebpart.wsp
使用管理中心
解决方案管理页可通过管理中心中的选项选项卡进行访问，在该页上，您可以删除不再部署的解决方案。只需单击解决方案名称，然后使用工具栏上的删除解决方案按钮即可。
使用 Windows SharePoint Services 3.0 对象模型
您还可以通过在 SPSolutionCollection 对象级别调用 Remove 方法来删除解决方案。此集合通过 SPFarm 类从本地场或加入到的场进行公布。以下代码可从解决方案存储区中删除解决方案。
SPFarm.Local.Solutions.Remove("hellowebpart.wsp");
升级解决方案
管理 SharePoint 解决方案的最后一个选项是将已部署的解决方案升级到新版本。理解在 Windows SharePoint Services 解决方案级别不执行版本控制极其重要。实际版本控制在解决方案组件级别（Feature、程序集等）执行。
图 25 概述了如何执行解决方案升级。
图 25. 升级 SharePoint 解决方案
假设已将 MySolution.wsp 的 1.0.0.0 版本添加到了解决方案存储区，并已部署到了一个或多个 IIS Web 应用程序。Windows SharePoint Services 解决方案的第二个版本必须具有相同的 SolutionID，升级才能成功。可通过调用带有 upgradesolution 选项的 Stsadm.exe 命令行实用工具使第二个版本进行升级。在解决方案存储区中，您需要提供要升级的解决方案的名称、解决方案的新版本，然后指定是计划升级还是立即升级。您还可以指定一些选项以允许在全局程序集缓存中进行部署，并允许自定义代码访问安全策略。
升级 SharePoint 解决方案指南
在讨论升级 SharePoint 解决方案指南时，我们必须区分基于代码的解决方案（如 Web 部件）和基于架构的解决方案（如自定义列表定义）。
-
升级 Web 部件解决方案 Web 部件是基于代码的解决方案的典型示例。升级基于代码的解决方案往往涉及使用更新过的程序集版本替换 IIS Web 应用程序的专用应用程序文件夹或者全局程序集缓存中的程序集。图 26 汇总了可能的升级途径。
图 26. 升级 Web 部件
如果您不更改 .NET 程序集的版本号，升级过程会顺利进行。通过保持程序集版本号不变，可确保已存储并且以某种形式可用（如 Web 部件库中的 .webpart 注册形式）的元数据无需更改。页面上 Web 部件的所有现有实例都可以轻松升级。
如果更改程序集的强名称（通常可能会是将版本号从 1.0.0.0 升级到 2.0.0.0），升级过程会有些复杂。如果没有在网站内创建任何 Web 部件实例，则不会出现问题。Web 部件库中的项使用新的 .webpart 文件进行更新，新版本的程序集被放入 bin 文件夹或者全局程序集缓存中。页面中新添加的 Web 部件内容反映了新的功能。
但是，当页面上存在旧版本的 Web 部件的现有实例时用户可能会收到错误消息，用户会决定执行升级。这些实例仍在查找程序集的第一个版本。使用 upgradesolution 选项时，较旧的程序集版本以及 web.config 文件的 safeControls 节中的项实际上就被删除了。
因此，您的方法是将升级 Web 部件解决方案和新版本的程序集结合，该程序集组合了承载 SharePoint 网站的 IIS Web 应用程序的 web.config 中的两个附加项。其中第一个附加项是用于程序集的第一个版本的 SafeControl 元素，第二个是在有对第一个版本的请求时，命令 ASP.NET 绑定到程序集的第二个版本的 bindingRedirect。
演练：升级 Web 部件项目
升级 Web 部件项目
-
开始构建一个小的 Web 部件项目，该项目输出一个字符串（例如，版本信息）。可以使用 Visual Studio 2005 Extensions for Windows SharePoint Services 3.0 来开始，但必须手动执行打包和部署。我们建议使用像图 27 中描述的那个结构一样的项目结构。以前讨论的关于手动对 SharePoint 解决方案打包的所有技术都将在此用到。
图 27. Web 部件解决方案的项目结构
-
在网站集中部署解决方案并激活 Feature，以便您将 Web 部件添加到其中一个页面（请参见图 28）。
图 28. Web 部件的第一个版本
-
假定存在更新 Web 部件的请求。用户要查看 Web 部件中稍有不同的字符串。首先，更改 Web 部件中内容的呈现，接着使用 Web 部件项目的属性将程序集的版本号从 1.0.0.0 更改为 2.0.0.0。生成项目。
-
打开 .webpart 文件并更新 type 元素的版本号。
-
生成项目并重新生成 SharePoint 解决方案文件。从批处理文件或命令提示符调用以下内容升级解决方案。
Stsadm -o upgradesolution -name VersionDemo.wsp -filename VersionDemo.wsp -immediate -allowgacdeployment
-
刷新含有 Web 部件实例的页面。图 29 显示了显示的错误以及很好地反映输出中的更改的新实例。
图 29. 显示错误及正确呈现的 Web 部件
-
解决显示的错误：
-
为 web.config 文件中的版本 1.0.0.0 添加 SafeControl 元素。
Xml
<SafeControl Assembly="VersionDemo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5" Namespace="MSDN.Samples" TypeName="VersionDemo" Safe="True" />
-
在 web.config 文件中的 assemblyBinding 元素下添加下面的元素用于重定向操作。
Xml
<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="VersionDemo" publicKeyToken="9f4da00116c38ec5" culture="neutral" /> <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" /> </dependentAssembly> … </assemblyBinding> </runtime>
-
-
刷新包含两个 Web 部件实例的页面。图 30 显示了最终的结果。现在，Web 部件的第一个版本对程序集的 2.0.0.0 版本也可用了。
图 30. 两个 Web 部件都运行正常
-
-
升级基于架构的解决方案 基于架构的解决方案的一个示例是自定义列表定义。通常，要在 SharePoint 站点上存在基于架构定义的实例时升级这些类型的解决方案，可以部署新版本的 Feature，然后将旧版本的 Feature 对用户标记为隐藏。这样，实例就不会中断，并且新实例遵循更新的定义。
演练：升级基于架构的解决方案
让我们回到在上文中作为 SharePoint 解决方案创建和部署的 Employees 列表模板。
假定用户已创建了此列表的许多实例。已决定进行更改，也可能完全删除列表定义。如前所述，您无法从 SharePoint 计算机中只删除解决方案文件。尽管它们对于管理员和用户不可见，但您需要保持它们继续运行。请注意，如前所述，此方法也是收回解决方案的一种替代方法。
下面是完成升级基于架构的解决方案的具体步骤。
升级基于架构的解决方案
-
打开包含列表定义的解决方案组件的文件夹，然后打开 feature.xml 文件。
-
将 Feature 元素的 Hidden 属性的值更改为 TRUE。
Xml
<Feature Id="{489C77F1-B064-408e-9B85-029A33BDF9D7}" Title="Employees" Description="This feature provides support for creating an Employee List." Version="1.0.0.0" Scope="Web" Hidden="TRUE" xmlns="http://schemas.microsoft.com/sharepoint/"> <ElementManifests> <ElementManifest Location="ListTemplates\Employees.xml"/> <ElementFile Location="Employees\allitems.aspx" /> <ElementFile Location="Employees\dispform.aspx" /> <ElementFile Location="Employees\editform.aspx" /> <ElementFile Location="Employees\newform.aspx" /> <ElementFile Location="Employees\schema.xml" /> </ElementManifests> </Feature>这会使 Feature 在管理页中隐藏起来，但您必须在创建页中也将其隐藏起来。
-
打开 employees.xml 文件并添加 Hidden 属性。
Xml
<Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <ListTemplate Name="Employees" Type="10100" BaseType="0" OnQuickLaunch="TRUE" SecurityBits="11" DisplayName="Employees" Description="Employees List Type" Hidden="TRUE" Image="/_layouts/images/CHNGCOL.GIF"/> </Elements>
如果您只想收回解决方案，上面的步骤足以实现。
但是，如果您要用新版本替换列表定义，则还需要向解决方案包添加以下内容：
-
标有不同 GUID 的新版本的 Feature（含有所有相关文件）。
-
扩展的指令清单文件，其中包含原始（很快会隐藏）版本和新版本的 Feature 的安装步骤。
-
扩展的 .ddf 文件，其中包含打包新的 Feature 和早期版本的 .wsp 文件中的条目。
在这两种情况下，您必须重新创建 SharePoint 解决方案文件，并使用前面提到的 Stsadm 的 upgradesolution 选项对其进行部署。
Stsadm.exe -o upgradesolution -filename package\Employees.wsp -name Employees.wsp –immediate
-
结束语
对开发人员和管理员来说，理解 Windows SharePoint Services 领域内的解决方案的概念极其重要。以多种方法创建应用程序和扩展 SharePoint 站点的开发人员必须打包 SharePoint 解决方案文件中的解决方案组件并将其提供给管理员。管理员有多种选择来将解决方案提供给 SharePoint 站点的用户。本文介绍的新的选择可用于将解决方案从中心解决方案存储区传送到前端 Web 服务器和应用程序服务器。本文还介绍了用于维护和升级已部署的解决方案的技术。
关于作者
Patrick Tisseghem 是一位 Microsoft Office SharePoint Server MVP，专门致力于研究 Windows SharePoint Services 3.0 和 Office SharePoint Server 2007。他针对最新版本 SharePoint 为 Microsoft Redmond 创建和提供了以 ISV 为中心的前期应用材料，而且巡游了许多国家/地区，举行他的以开发人员为中心的研讨会。他经常在重要的 Microsoft 会议（如 TechEd 和 SharePoint Connections）中发表演讲，是发布在 MSDN 上的许多白皮书的作者。他还是 MOSS 2007 深入探讨 一书的作者，此书由 Microsoft Press 出版。有关 Patrick 的更多信息，可以在他的博客中找到。
转载于:https://www.cnblogs.com/xioxu/archive/2009/12/03/1616130.html
发布者：全栈程序员-用户IM，转载请注明出处：https://javaforall.cn/110837.html原文链接：https://javaforall.cn
【正版授权，激活自己账号】： Jetbrains全家桶Ide使用，1年售后保障，每天仅需1毛
【官方授权 正版激活】： 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...
