通过STSDEV简化SharePoint开发

　　目录

　　RootFiles 目录

　　自动生成解决方案包

　　STSDEV 入门

　　使用 MSBuild 创建自定义生成目标

　　扩展 STSDEV 实用程序

　　我 从 2005 年夏天开始开发 Windows® SharePoint® Services (WSS) 3.0 和 Microsoft® Office SharePoint Server (MOSS) 2007。从那时起，我已经创建了数以百计的新类库项目并手动对其进行了配置，以开发各种类型的 SharePoint 组件，如“功能”、“应用程序页面”、“页面模板”和“Web 部件”等。

　　不久以后，我又开始标准化解决方案中的文件和文件夹的公用项目结构，这些解决方案都是我使用面向 SharePoint 开发的 Visual Studio® 2005 创建的。但是，这是一个痛苦的过程：对于每个项目，仅创建作为起点的基本结构就要花费五到十分钟的时间。而各项目之间除项目名不同以外，源文件几乎完全相同。

　　许多开发人员在进行 SharePoint 开发时还会面临另一个艰巨问题，那就是创建必需的文件以生成测试和部署时所需的解决方案包文件 (.wsp)。与许多其他 SharePoint 开发人员一样，我也习惯了手动创建和更新 manifest.xml 文件和 .ddf 文件来生成自己的解决方案包。

　　在过去的一年中，我一直在与其他一些 SharePoint MVP（包括 John Holliday、Andrew Connell 以及 Scot Hillier 等）合作，为实现同一个目标他们都提出了非常相似但又略有不同的架构。我们讨论了有关设计和实现代码生成器的构思，它可以为新的 Visual Studio 项目和解决方案自动产生所需的全部源文件。最终目标当然是为启动和运行新的 SharePoint 开发项目提供更快的方法。

　　在创建了可生成具有公用文件夹结构的每个新 Visual Studio 解决方案的代码生成器后，才有可能编写所需的代码来重新生成产生解决方案包 .wsp 文件所需的 manifest.xml 文件和 .ddf 文件。这样就避免了手动修改 manifest.xml 或 .ddf 文件的需要。

　　本月专栏将介绍一个名为 STSDEV.EXE 的概念验证应用程序，此程序演示了如何为 SharePoint 开发创建简单的代码生成器。STSDEV 是一个控制台应用程序，它非常便于开发 MOSS 2007 的组件。另外，它能够以可重复的方式生成代码，这就使得为遵循最佳实践的 SharePoint 开发生成 Visual Studio 解决方案成为可能。

　　在本月专栏中，我的目标是讨论如何使用 STSDEV 实用程序创建和扩展 Visual Studio 项目，为 SharePoint 开发创造有效灵活的环境。此处所概述的方法非常灵活，因为它既可以用于 Visual Studio 2005，也可以用于 Visual Studio 2008。而且，当需要从一个版本的 Visual Studio 移动到另一个版本时，此方法还非常容易迁移。

　　RootFiles 目录

　　要想了解 SharePoint 开发中有关部署的工作原理，其中一个重要方面就是要知道需要将模板文件复制到前端 Web 服务器上的哪个位置。大多数文件都必须部署到各个前端 Web 服务器上一个名为 SharePoint RootFiles 的目录内，在 WSS 3.0 中此目录位于：

　　C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12

　　请查看在 RootFiles 目录中嵌套的子目录。在绝大多数情况下，需要部署自定义模板文件的目录都是 TEMPLATE 目录。但有时也需要将文件部署到其他一些子目录中，如 ISAPI 目录（部署自定义 Web 服务时）和 Resources 目录（需要部署具有全局资源的 .resx 文件时）。

　　Figure 1文件夹在 RootFile 中

　　TEMPLATE 目录还包含数个重要的子目录。例如，每个自定义功能都需要其自己的命名目录位于 FEATURES 目录中，其中包含名为 feature.xml 的特征指令清单。应用程序页面应被复制到 LAYOUTS 目录内的子目录中。

　　自动生成解决方案包

　　在 MOSS 2007 开发中使用解决方案包部署所有自定义模板和组件，这是一个最佳实践。实际上，如果您曾遇到过无法通过解决方案包部署的组件类型，则在设计和部署基于 SharePoint 的解决方案时应考虑加以避免，因为它会影响在生产或分段环境中安装、维护和升级开发工作的能力。

　　开发 WSS 3.0 或 MOSS 2007 时，应配置 Visual Studio 项目以生成自己的解决方案包，并应在任何项目的开发周期中提早完成。我曾发现有许多开发人员将创建测试用解决方案包的工作推迟到开发生命周期的晚期，这样做可能会引发一些问题和无法预料的延迟。最好做一些额外的工作来配置 Visual Studio 项目，以立即生成解决方案包并使用解决方案包部署来执行所有测试。

　　那么如何配置 Visual Studio 项目才能自动生成代表解决方案包的 .wsp 文件呢？您可以有多种选择：例如，您可以编写一个调用 MAKECAB.EXE 实用程序的批处理文件来生成 .wsp 文件，然后在 Visual Studio 中通过生成事件来调用它。不过，虽然此方法提供了一种快捷简易的途径来通过 Visual Studio 生成流程自动运行命令，但是使用自定义的生成目标会更加灵活而且更易于维护。

　　STSDEV 实用程序设计用于创建 Visual Studio 解决方案，以便直接在 Visual Studio 开发环境中运行许多特定于 SharePoint 的命令序列。每当 STSDEV 实用程序创建一个新项目时，它都会通过多种不同的配置来执行此操作，并会向每种配置中添加一个 MSBuild 自定义生成目标。这样就可以仅在配置之间进行切换，然后再运行标准 Visual Studio 生成命令来执行特定的生成目标。此目标包含在 SharePoint 开发中使用的常用命令序列，如使用 MAKECAB.EXE 实用程序生成解决方案包，然后使用 STSADM.EXE 实用程序在本地场中对其进行安装和部署。

　　STSDEV 入门

　　先让我们快速了解一下 STSDEV 实用程序的工作原理。开始时您可以运行 STSDEV 而不传递任何参数。实用程序将弹出一个对话框，提示用户选择要生成的 SharePoint 开发解决方案类型。

　　Figure 2使用 STSDEV 创建 Visual Studio 解决方案

　　STSDEV 实用程序在设计时充分考虑了可扩展性。每种可用的解决方案类型基本上都是一个解决方案提供程序类，通过它实现的名为 IsolutionProvider、特定于 STSDEV 的接口非常简单：

　　public interface ISolutionProvider {

　　string Title { get; }

　　void InitializeSolution();

　　void AddSolutionItems();

　　}

　　此设计的目的旨在使高级 SharePoint 开发人员能够通过创建其自己的解决方案提供程序来轻松扩展 STSDEV，然后这些提供程序可以为特殊方案生成 Visual Studio 项目，或用来满足特殊公司的标准和原则。

　　但是，使用 STSDEV 创建的每个解决方案和项目会始终共享公用结构和用于生成输出解决方案包的标准部署文件集。STSDEV 实用程序还会创建具有标准配置集和自定义生成目标的各个 Visual Studio 解决方案，允许开发人员自动化在开发期间需要用到的许多操作，如安装、部署或收回当前项目的解决方案包。

　　为了得到更好的方法，让我们检查一下使用空解决方案提供程序生成的 HelloWorld 解决方案的结构。STSDEV 生成一个名为 HelloWorld.sln 的解决方案文件和一个名为 HelloWorld.csproj 的项目文件，这可以使用 Visual Studio 2005 解决方案格式或 Visual Studio 2008 解决方案格式来创建。另外还要注意，STSDEV 实用程序使用标准类库项目类型创建 Visual Studio 项目，这会有利于将 Visual Studio 2005 项目升级到 Visual Studio 2008。

　　Figure 3HelloWorld 项目结构

　　STSDEV 实用程序会使用其标准项目结构创建一个名为 DeploymentFiles 的文件夹和另一个名为 RootFiles 的文件夹。DeploymentFiles 文件夹包含四个文件，用于生成、部署和调试输出解决方案包：

　　Manifest.xml 解决方案包 manifest 对 SharePoint 而言是必不可少的，必须将其内置于输出解决方案包文件中（例如 HelloWorld.wsp）。

　　SolutionPackage.ddf 一个菱形定义文件，在 MAKECAB.EXE 实用程序中用作输入来生成解决方案包文件。

　　SolutionConfig.xml 一个用于 STSDEV 的文件，可跟踪重新生成 manifest.xml 和 SolutionPackage.ddf 所需的其他解决方案元数据。此元数据包括解决方案 ID 的 GUID、输出解决方案包的名称以及可选的其他程序集部署信息，如 SafeControl 条目和自定义的“代码访问安全性”(CAS) 设置。

　　Microsoft.SharePoint.targets 一个包含 MSBuild 格式的自定义生成目标的文件，可用在 SharePoint 开发中。

　　虽然 DeploymentFiles 文件夹始终包含这四个文件，但是 RootFiles 文件夹的内容却随着所选解决方案类型的不同而变化。在您创建空解决方案时，RootFiles 文件夹最初并不包含任何文件或文件夹。但是，RootFiles 文件夹是您添加各个模板文件的位置，该模板文件在每个前端 Web 服务器的 RootFile 目录中都需要进行部署。

　　每次将新文件添加到 RootFiles 文件夹时，都需要更新 manifest.xml 文件以及 SolutionPackage.ddf。不过，在您每次重新生成项目时，STSDEV 实用程序可以为更新这些文件提供便利。它借助 RefreshDeploymentFiles 命令来实现此目的，该命令通过枚举它在 RootFiles 目录中找到的文件夹和文件来重新生成 manifest.xml 和 SolutionPackage.ddf 文件。

　　我们来看一个示例。创建空解决方案时，manifest.xml 文件如下所示：

　　SolutionId="24F91DED-8BA7-4633-8BA0-4C9B2A4387D7"

　　ResetWebServer="True"

　　xmlns="http://schemas.microsoft.com/sharepoint/" >

　　同样，SolutionPackage.ddf 文件如下所示：

　　; Generated by STSDEV at 1/7/2008 8:42:21 AM

　　.OPTION EXPLICIT

　　.Set CabinetNameTemplate=HelloWorld.wsp

　　.set DiskDirectoryTemplate=CDROM

　　.Set CompressionType=MSZIP

　　.Set UniqueFiles=off

　　.Set Cabinet=on

　　.Set DiskDirectory1=DeploymentFiles

　　DeploymentFilesmanifest.xml