摘要：学习开发Windows SharePoint Services 3.0的技能，与传统ASP.NET开发的区别，需要的开发环境，用Visual Studio 2005 Extensions for Windows SharePoint Services 3.0建立Windows SharePoint Services解决方案的步骤。这是文章的第一部分。

Patrick Tisseghem, U2U

June 2007

 

应用：Microsoft Windows SharePoint Services 3.0, Visual Studio 2005 Extensions for Windows SharePoint Services 3.0

 

内容：

Ø 介绍开发Windows SharePoint Services的技巧

Ø 需要的开发技能

Ø ASP.NET Applications vs. SharePoint Sites

Ø 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解决方案的技术。这篇文章也包含了一个Walkthrough介绍了开发人员和管理员可以获得的手段和方法。

 

人们常问成为一个SharePoint Developer需要什么样的必备条件，而且对于Developer需要掌握并精通很多技术而感到惊讶。

下面是一个关于我们需要熟练掌握的技术领域的列表，对成为一个SharePoint Developer会很有帮助。

最新版的Windows SharePoint Services和Microsoft Office SharePoint Server (MOSS) 200完全依靠 Microsoft ASP.NET 2.0为基础。因此，掌握ASP.NET 2.0的概念、技术和开发是一个Windows SharePoint Services开发人员最先需要掌握的技术。此外，明白ASP.NET请求的流程和它的不同阶段，还有它的内部结构和扩展属性，一个Developer必须对开发、使用母版页和内容也很有经验，ASP.NET服务器端控件和用户控件，ASP.NET的模板，ASP.NET
Web Part和它们的基础构架，ASP.NET提供者模型。（关于这些技术有许多文章可以学习，但并不是本篇文章涉及的内容。）

当一个信息工作者在一个Windows SharePoint Services解决方案上工作时，你经常需要自定义工作流。MOSS 2007内置的工作流在一定程序上可以满足业务需求，但是Developer经常会问如何使用Windows Workflow Foundation (WF)扩展和创建SharePoint工作流的项目模板来建立自定义工作流。Developer需要很好的了解WF，包括建立工作流的过程，建立自定义Activity，workflow和SharePoint环境结合使用等。

Windows SharePoint Services很大程序上依赖于XML技术。这是很多Schema定义的基础，例如站点、列表、文档库、字段、内容类型等。在这些Schema的定义中的大部分使用Collaborative Application Markup Language (CAML)。此外，Developer必须了解相关的XML技术，像XSLT和XPath都会在Windows SharePoint Services开发中遇到。

一个Windows SharePoint Services Developer必须了解Windows SharePoint Services 3.0和MOSS 2007中暴露的APIs。Windows SharePoint Services建立的解决方案需要深入的了解对象模型暴露出来的类。此外，应用需要在远程的Smart Client上工作并和SharePoint进行交互，关于Windows SharePoint Services和MOSS的XML
Web Services技术也是必须的。

 

最后，所有的解决方案都必须是可部署并在服务器场一定范围内的一定级别上可用（例如，一个站点集）。必须明白将不同的组件整理后如何打包成解决方案，如何安装并激活相应的Feature，让解决方案在新建或现有站点均可用。这篇文章提供了很多信息和指南来教你如何做这些事情。

 

Windows SharePoint Services开发和传统的ASP.NET开发有很多不同。为了帮助你明白这些不同，我们比较一下ASP.NET应用和Windows SharePoint Services应用。

下图显示了ASP.NET应用主流的组成和交互的流程。

用户向运行Internet Information Services (IIS)服务器发送一个请求。这些请求被接受，并委派给ISAPI继续处理，它是扩展名为DLL的组件。通常，从文件系统中获取资源，例如.config文件，.aspx文件，cascading style sheets，自定义建立的.NET组件，还有用户控件。所有这些都会对最后的响应起作用，并将他们返回到用户的浏览器上。很多应用中，和数据存储进行交互时，也需要在请求和响应的过程中存储和提取数据。

那么，我们来比较一下上图和下图的区别，下图显示了一个基于Windows SharePoint Services站点的组成和流程。

如图所示，Windows SharePoint Services将开发人员从关注的很多细节中抽象到一个比较高的层次，模板驱动站点。在大多数情况下，SharePoint管理员和有经验的用户不需要接触到底层架构。尽管如此，了解它还是有帮助的。

Windows SharePoint Services是一个站点提供的引擎，很大程度上Schema定义的模板对于它们的运行环境都很重要。站点模板的定义；基础结构的页面像作为工作组站点的首页default.aspx；列表和文档库；帮助页面可以帮助你如何让存储在不同容器中的内容进行交互。

当Windows SharePoint Services页面开始一个请求时，会与配置数据库和内容数据库进行交互并提取出与请求相关的详细内容。这包含访问很多包含Schema定义的XML文件，并访问一些基础部分（Web Part），每一个都需要执行他们压缩在.NET组件中的代码，这些组件放在Bin或者GAC中。Windows SharePoint Services提供引擎会参与所有这些过程。

当我们重新再看传统的ASP.NET开发时，当你需要更多的应用时，1个，可能2个，5个甚至12个会发生什么？ASP.NET图看起来会非常复杂，相同的结构要为每一个应用都做一遍。Developer可以根据下面的最佳实践和模式来建立很多可以重用的基础部分，但是基础架构每次都需要被重建。

比较起来，更多的Windows SharePoint Services站点——12个、上百、甚至上千的协作站点——都可以由一个普通的提供引擎来做。这就是使用Windows SharePoint Services相对于ASP.NET应用的强大之处。

 

Windows SharePoint Services可以开发什么

Windows SharePoint Services是一个解决方案平台，它的可扩展性已经准备找来运行自定义解决方案了。以下部分是讨论Windows SharePoint Services Developer可以建立的解决方案类型。

这些方案是基于代码的解决方案。基于组件的解决就是开发管理代码（一种.NET Framework语言，例如Microsoft Visual C#或Microsoft Visual Basic 2005）然后编译成一个.NET组件（一个DLL）。你也可以建立不同类型的解决方案。下表描述了一些基于组件解决方案。

第二张图展示了Windows SharePoint Services站点的基础结构。结构中包含了很多ASP.NET的内容，这些可以帮助你简化Windows SharePoint Services的开发。作为一个Developer，你可以创建和继承自己开发的东西。下表列出了你可以创建的内容。

Schema是基于XML的解决方案，使用Collaborative Application Markup Language (CAML)语言。下表列出了哪些特性可以使用 Schema开发或修改。

所有的内容都在SharePoint站点中存储和管理，而且所有的配置数据都存在SQL Server数据库中，你不需要直接来操作它们。Windows SharePoint Services和MOSS由一系列的.NET组件提供了十分丰富的对象模型，其中比较重要的有Microsoft.SharePoint.dll和Microsoft.Office.Server.dll两个组件。

在服务器场中的一台服务器上部署应用以后，只能在这台服务器*问这些服务器端的对象模型。如果应用需要访问的Windows SharePoint Services是在远程部署的，那么要使用Web Services APIs来代替。

解决方案会与SharePoint的类直接进行交互，但是需要具有SharePoint站点（无论是协作站点还是管理站点，依赖于解决方案的类型）的上下文才行。例如，部署在Windows SharePoint Services服务器上的Windows应用程序，运行在Windows SharePoint Services上下文中的Web Part，自定义方式获取数据的自定义Web Services，运行在SharePoint服务器上的Windows服务等等。

Windows SharePoint Services默认提供了很多的Web Services可用，满足了大多数数据操作的情况。尽管如此，当需要自定义功能的时候，仍然可以创建自定义Web Services并且和Windows SharePoint Services内置的一样和Windows SharePoint Services进行交互和集成。

还有支持HTTP的协议，FrontPage Server Extensions Remote Procedure Call (RPC)协议，是远程客户端在操作Windows SharePoint Services文档库中存储的文档时使用的。智能客户端中例如Microsoft Office系统客户端就是使用这种协议。

 

Developer可以使用两种环境来创建SharePoint解决方案。你的选择会依赖于不同的因素，包括网络结构、许可、团队大小、创建解决方案的类型。在这篇文章中，我们将推荐一种我们认为的最佳实践。

在安装中我们描述，Developer在一个本地操作系统为非服务器操作系统并安装了Microsoft Visual Studio 2005的机器上工作。

他们建立解决方案，然后根据下面的步骤在运行Windows SharePoint Services 3.0的中心服务器上部署这些解决方案，也可能是MOSS服务器。

依赖于解决方案的类型，特别是.NET组件（例如，Microsoft.SharePoint.dll）必须拷贝到本地的开发环境中。

这样工作有很多好处。第一点很重要的就是Developer不需要在本地用来开发的电脑上安装服务器软件。这样可以避免License的问题，而且也可以减轻Developer的需要作很多开发工作的电脑的负担。第二点好处就是你可以建立一个源代码管理的系统，管理员也可以集中管理并进行备份。

尽管如此，Developer用这种方式工作也会有一些困难的地方。首先，远程调试代码就是一种挑战。例如，开发Web Part的时候就需要进行代码调试，你必须考虑到很多环境变量：

l Developer调试一个站点的解决方案时需要服务器上一个比较高的权限。

l Developer也会影响到其它在同一站点上工作的Developer。

l 每次调试的时候，Developer必须打包代码并且重复服务器上的部署工作，然后才能看到代码运行的效果。这样虽然有一定的好处，但是Developer必须小心的打包然后部署等，但是这种方法有可能不能达到预期的工作效率。

注意：

很多基于组件的解决方案都需要在运行Windows SharePoint Services的服务器重启IIS才能激活更新的版本。

你也可以在本地配置开发环境，让SharePoint开发在本地进行。

推荐这种配置有以下几种原因：

最终，开发人员开发（创建、测试、调试）可以在本地进行。例如在本地建立基于组件的解决方案这种情况。

测试解决方案不会影响到同事的工作。但是，本地开发需要更多的规范来约束Developer。例如，建立一个有效的备份和源代码管理系统，会在这种情况下更有难度。

本地开发环境既可以是安装了Windows SharePoint Services 3.0的Windows Server2003也可以是MOSS。但是有一点需要说的就是，如果这个Developer在同一台电脑上还有其他的开发工作会使电脑的负担增加很多。一个配置好的Microsoft Virtual PC开发环境是一种不错的选择，但是这种方法需要更多的内存和磁盘空间。

 

Visual Studio 2005 Extensions for Windows SharePoint Services 3.0可以改善你一些开发任务的工作效率。它提供了如下内容：

l 创建Web Part、工作组站点、空站点和列表定义的项目模板。

l 向现有项目添加单个项目的模板，例如Web Part类、自定义子段控件、Module，还有列表定义、内容类型等（都具有Event Receiver）。

l 一个名为SharePoint Solution Generator的扩展Windows应用，可以获得一个工作组站点，对它进行反向工程，将提供给你在Visual Studio 2005项目中所有的各个组件。

记住这点很重要，Visual Studio 2005 Extension在开发过程中提供给Developer，并且包括测试和调试阶段。使用这篇文章中的Walkthrough扩展可以允许你的注意力只在代码上，仅需要开始编写就行，不需要首先设置这个项目的基础结构，然后编译代码并打包进Windows SharePoint Services解决方案，最后部署到你的那个网站集中然后才能进行测试和调试。

尽管如此，你可以使用很少的配置选项来脱离默认的解决方案打包和部署的方法。这个不同的场景是，你需要用后面提到的手工的方式将控件打包然后部署解决方案。

下面是一些Walkthrough来教展示一些可以用Visual Studio Extensions for Windows SharePoint Services 3.0来承担的开发任务。

如果你对Visual Studio Extensions for Windows SharePoint Services 3.0很熟悉，并且用它创建过Web Part，你可能想要进入下一部分。但对于不太熟悉这个扩展的读者，这个简短的Walkthrough将描述一些简短的步骤来创建一个Web Part项目，展示世界上著名的Hello World字符串。（不用担心，它将很令人兴奋的。）

1．打开Visual Studio 2005，创建一个Web Part项目。

在解决方案浏览器中，注意到已经引用了Microsoft.SharePoint.dll和the System.Web.dll。最后一个引用比较重要，因为WebPart1.cs文件中包含的类是集成自ASP.NET 2.0 WebPart类的。这是一种新的创建Windows SharePoint Services 3.0的Web Part类的方式。

2．仅需要编写下面展示的很少量的代码就可以在WebPart中输出一个字符串。最终的代码如下所示：

3．在测试Web Part之前，完成下面的配置任务。如下图中显示，通过解决方案浏览器打开项目属性，点击SharePoint Solution选项卡。

后面我们会解释Feature和解决方案的概念，现在，XML文件包含的元素暴露在这里：

l Solution节点，包括Solution的Name和ID。

l 描述Feature.xml文件的节点，在/12/Template/Features路径下创建的文件夹的名字可以被修改。此外，这个节点还显示了Title、Description和Scope（默认情况下，设置为网站集级别）。

l 描述manifest（elements.xml）文件的节点，可以设置Web Part的Title和Description。

注意：

那些灰色的特性不能修改。例如，Web Part项目，没有办法修改feature.xml文件和注册的Event Handler。后面会描述这个问题。

4．在Visual Studio 2005中，按F5来安装SharePoint解决方案并将它部署到IIS中的Web应用中。在调试选项卡中指定在哪里将Web Part作为一个Feature激活。

在文章的后面将解释后台都做了什么。简言之，代码被打包进一个SharePoint解决方案，然后将这个解决方案添加到服务器场中，最后将它部署到站点集中。这时，就可以在页面上添加这个Web Part了。

Visual Studio 2005 Extensions for Windows SharePoint Services 3.0也提供了开发其它类型的SharePoint解决方案。例如，可以创建一个空的项目然后分别添加不同的项模板。下面的步骤是创建一个简单的字段类型，然后在Windows SharePoint Services开发环境中快速简单的部署并激活它。

1．打开Visual Studio 2005，创建一个新的SharePoint项目。

这时并没有为你创建任何东西。当然！你选择的是空项目！但是现在你可以添加一个基于Field Control模板的项。下面创建的这个是一个简单的字段，捕获、存储使得项目引用的编码可用。（在这个过程中有一个小小的逻辑验证，强制输入一个长度为3的数字。）

2．完成后，添加了两个类，一个是Custom Field另一个用来输出一个控件展示自定义方法捕获到的Field的值。需要添加代码的是ProjectReferenceNumberField类。添加如下方法：

3．在按F5之前，配置一下项目属性。这次，SharePoint Solution选项卡中没有feature.xml文件，但是有另一个前缀为fldtypes的XML文件可以配置，它放置在/12/TEMPLATE/XML文件夹中。可以设置TypeDisplayName和TypeShortDescription的值。同样，还需要在调试选项卡中的使用URL启动浏览器中设置好网站集的路径。

4．按F5。下图展示了一个新的字段类型如何在列表可用字段类型中列出。

下图展示了验证部分的代码验证字段值的长度后给用户返回的错误信息。

这个例子演示了如何使用Visual Studio 2005 Extensions for Windows SharePoint Services 3.0的SharePoint Solution Generator来反向工程一个已经存在的SharePoint工作组站点（也可能是一个自定义的）。Walkthrough向你演示如何反向工程MSDN提供的可下载的40个网站模板。它们大部分都以.stp文件的形式提供（这是在浏览器中使用将当前网站另存为模板得到的结果）。

注意：

你可以在这里下载这些模板Application Templates for Windows SharePoint Services 3.0。

在这个Walkthrough中，我们给SharePoint Solution Generator提供一个Sports League模板，然后生成一个.NET项目，其中包含站点定义的各个组件和Feature。

1．下载Sports League模板，安装它并将它上传到一个网站集的网站模板库中。

2．基于这个新的模板创建一个网站。网站效果如下图：

3．开始使用SharePoint Solution Generator之前，删除页面上那个图片的Web Part。

4．打开SharePoint Solution Generator，点击Site Definition，然后进入下一步。

5．输入想要进行反向工程的站点的URL，或者在树中找到它的位置。

然后指定创建Visual Studio项目的位置。

6．点击Start即可开始解决方案的生成。

7．当解决方案生成器生成完成后，你可以打开这个Visual Studio 2005项目。

可以看到项目中有不同类型的内容，讨论它们不是本文的范围。但是，你可以看看列表、库、站点的Schema定义。

8．按F5可以使所有内容在你的开发环境电脑上可用。你可以配置很多它们的这些细节内容，同时也包括SharePoint Solution选项卡中的内容。

 

深入研究Windows SharePoint Services解决方案

使用Visual Studio 2005 Extensions for Windows SharePoint Services 3.0的一个好处就是开发成果可以被打包进一个SharePoint解决方案。对于Developer来说可以很快在他自己的电脑上测试代码，但是，需要改变打包和部署时的配置参数并不是很灵活。

我们使用的Solution是一个官方术语，它就是我们前面提到的打包，可以将你的自定义Windows SharePoint Services开发工作的成果以包的形式安装部署到前端Web服务器上，也可能是服务器场中的应用服务器。下图列出了可以进行打包的组件。这些组件包括：

l .NET组件将代码打包起来作为解决方案提供。

l 部署文件，例如，资源文件、图片或者其他的帮助文件。

l 其他的解决方案，包括提供网站、列表、库、字段、内容类型等的新模板和定义。这些定义都是基于CAML语言的XML文件。

l 在前端Web服务器级别的配置内容（例如，注册Web Part的web.config文件）。

除了这些，还必须有一个很重要的文件——manifest文件来辅助Windows SharePoint Services解决方案的部署过程。Manifest是一个XML文件。这个文件描述了在解决方案中的内容、内容部署的目标位置和它们的配置信息。

manifest文件中一般包含什么内容？很多——下面对每种类型做简要的说明。开始之前，你会注意到manifest文件的Schema定义在Wss.xsd文件中，它在WSS的系统文件夹下。

注意：

你可以在这个路径中找到WSS的系统文件夹C:/Program Files/Common Files/Microsoft Shared/Web Server Extensions/12。

所以你可能想要将这个文件添加到Visual Studio 2005环境中来获得更智能的服务。

Solution元素是manifest文件的根元素。SolutionId特性是文件一个很重要的元素。SolutionId是在Solution存储（是配置数据库的一部分，文章的后面将会讨论到）中用来识别Solution的。用一个GUID来标识这个Solution。

DeploymentServerType和ResetWebServer是可选特性。DeploymentServerType有两种可能的值：ApplicationServer和WebFrontEnd。通常情况下，大部分解决方案都指到服务器场中的前端服务器上。指到应用服务器（例如，索引服务器、Excel
Services运算服务器、文档转换服务器等等）上解决方案的例子中一般是自定义配置或者自定义转换。IISReset特性可以用来当解决方案部署到IIS的Web应用上时重启Information Services (IIS)。

Feature在Windows SharePoint Services中扮演了一个很重要的角色，因为它可以将一个Solution中的各个不同内容（例如，字段类型、Web Part、工作流等）分离开来。

在FeatureManifest元素中必须描述包含在Solution中的每一个Feature。下面的代码包含了在一个SharePoint站点上声明一个Web Part的Feature。

当你将这个Solution部署到Web服务器上时，所有在Feature中提到的文件都会被拷贝到本地相应的位置中。

很多SharePoint Solution都包含一个或多个.NET组件。Assembly元素就是manifest文件中用来保证这些DLL文件在目标服务器上可用。下面是一个例子。

Assembly元素的第一个特性就是Location，存储DLL文件在解决方案中的相对路径。然后就是DeploymentTarget特性，有两个可能的值：GlobalAssemblyCache或WebApplication。GlobalAssemblyCache表示组件需要被部署在global
assembly cache中；WebApplication告诉Windows SharePoint Services将组件放到IIS Web应用程序中的某一个应用程序文件夹中。WebApplication表示Solution的使用依赖于管理员设置的与IIS Web应用程序相关的web.config文件的信任级别。将组件部署到GAC中，这是一个全局信任的位置，做为一个Developer不需要担心设置它的信任级别。

Solution中的Web Part必须在web.config文件中注册为Safe Controls。Assembly元素可以包含一个或多个SafeControl元素（作为SafeControls的子元素）。每个SafeControl元素都描述了需要在web.config文件中作的配置。

Assembly元素的另一个子元素是ClassResource元素（作为ClassResources的子元素）。每个都描述了部署组件时需要的内容。例如，资源文件、XML文件、图片。

manifest文件包含了一个或多个ApplicationResourceFile元素，每个元素中都存储了部署是资源文件的相对路径。下面的代码示例了在部署的时候，资源文件会被拷贝到IIS Web应用程序中的一个应用程序的资源文件夹中。

当需要给你的代码授予相应的权限的时候这个元素是很重要的。后面会有更详细的讨论。简单来说，CodeAccessSecurity元素有一个或多个PolicyItem子元素，每个子元素都定义了Solution中的代码访问安全策略的精确权限。有两部分策略项：权限列表和组件具有的权限。

权限列表每个都表现为一个IPermission元素，均在PolicyItem的PermissionSet子元素下。每个IPermission元素都定义了一个组件正确运行需要的代码访问安全权限。后面将会详细讨论。

一个或多个Assembly元素作为一个代码访问安全中的角色。你必须一个一个的定义它们，用name、version、full public key来标识。

在将Web Part添加到Web Part页面上时要保证Web Part在Web部件库中可用。是一个XML文件，后缀名为.dwp或.webpart，包含了Web Part的一些元数据的信息。解决方案的manifest文件可以包含一个或多个DwpFile元素，作为DwpFiles的子元素，每个指向一个文件。

可以将资源文件放到包含Feature的文件夹中并使用。一个Resource元素描述了解决方案manifest文件中的一个资源文件。仅需要设置包中资源文件的相对路径这个特性。

当部署一个自定义站点定义时会用到这个元素。SiteDefinitionManifest元素有一个Location特性，它会识别出需要的文件夹并在/12/Template/SiteTemplates目录下创建。WebTempFile子元素部署webtemp*.xml文件并且使得Windows SharePoint Services知道这些文件。

在manifest文件中插入RootFile元素后，就可以在部署的时候将解决方案中的文件拷贝到/12目录下的指定目录中去。

TemplateFile元素用来定义部署的时候需要被拷贝到/12/Template目录下的模板文件。例如，定义自定义字段类型的fldtypes*.xml文件。使用Location属性来指定路径。

 

文章前面提供了三个Walkthrough，分别是创建部署WebPart的步骤、自定义字段类型和自定义站点定义。我们来看一下每个解决方案包含的不同文件。

首先来看一下生成一个简单的WebPart的那个解决方案。在Project的/bin/debug路径下，你会找到.wsp文件和一个名为solution的子文件夹，其中包含了需要打包进.wsp文件的所有文件。下图显示了Web Part Solution中的所有组件。

其中有个文件夹包含了Feature中的3个文件使得Web Part可用：feature.xml，elementManifest.xml，和HelloWebPart.webpart。下面是组件在manifest文件中的代码。

代码包含了两个主要的块。第一部分是FeatureManifests元素，告诉Windows SharePoint Services将Feature的文件拷贝到服务器12/Template/Features文件夹下。第二部分是Assemblies元素，有两个任务：将组件部署到GAC中，定义了web.config文件注册SafeControl需要修改的内容。

第二个解决方案是自定义字段类型。同样会在/bin/debug路径下的solution文件夹中的根目录下找到组件和manifest文件，但是不同的是，找不到名为Feature的子文件夹，取而代之的是一个名为xml的文件夹，其中包含了需要部署的模板文件，fldtypes*.xml文件。

manifest文件如下：

其中也是两部分内容：一个是部署的模板文件和它的部署路径，第二个是要部署的组件。SafeControl要求并不严格，除非这个字段类型被用作发布页面中的自定义字段控件。

最后一个解决方案类型是用SharePoint Solution Generator导出的Windows SharePoint Services站点，使用的是Sports League的例子。下图显示了生成.NET Project中包含的内容。

首先可以看到站点定义很重要的核心Schema文件，onet.xml和webtemp*.xml。在提供站点时包含执行代码的组件。至于其他的Schema，可以在Project中看到很多Feature的定义——站点、提供代码、列表、文档库。manifest文件内容如下：

代码中与前面例子不同的部分是最后的SiteDefinitionManifests元素部分。SiteDefinitionManifest元素定义了/12/Template/SiteTemplates文件夹中的站点定义，WebTempFile元素同样定义了webtemp*.xml文件。

 

最后一个例子就定义一个自定义列表。

1．打开一个站点集，然后根据自定义列表模板创建一个列表。

2．将列表命名为Employees，添加下列的栏：First Name，Last Name（修改Title栏），Department，Telephone Number。

现在可以使用SharePoint Solution Generator来生成自定义列表定义。

3．打开SharePoint Solution Generator，选择List Definition。

4．输入站点的URL并选择刚才创建的列表。

5．填写好创建Visual Studio Project的路径，点击Start按钮来开始生成。

6．下面来构造这个新建列表模板的Feature。在文件系统中选择一个路径创建一个文件夹，然后在它下面创建一个子文件夹Features。

7．在Features文件夹下创建了另外一个子文件夹EmployeesList。将.NET Project中Employees文件夹下的内容全部拷贝到这个文件夹中。

8．在EmployeesList文件夹级别创建一个feature.xml文件，并写入以下内容：

9．在EmployeesList文件夹下创建ListTemplates文件夹。然后在其中创建Employees.xml文件，并写入CAML语法的列表模板定义。

10．在Employees文件夹下打开schema.xml，确保根元素的Type特性与Timesheets.xml使用的Type一致（例子中是100）。打开每个.aspx页面，删除第一行注释。

现在Feature准备好了。然后你需要将他们打包成SharePoint解决方案。

1．在根文件夹级别创建manifest文件。

2．在同一级别创建一个.ddf文件，将所有内容打包进解决方案文件。

3．将所有内容打包进.wsp文件，将解决方案添加到解决方案存储，然后使用下面的命令进行全局部署。（将它们放到批处理文件中）

现在可以尝试在站点的Feature页面来激活Feature，用新的列表模板来创建新的列表。后面涉及到取消和升级这个解决方案的时候还会用到这个解决方案。

下一篇文章：Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (Part 2 of 2)

 

Patrick Tisseghem is a Microsoft Office SharePoint Server MVP, and is highly focused on Windows SharePoint Services 3.0 and Office SharePoint Server 2007. He created and delivered the ISV-focused early
adopter material for Microsoft Redmond for the latest version of SharePoint and has toured many countries with his developer-focused workshops. He is a frequent speaker at major Microsoft conferences such as TechEd and SharePoint Connections, and is the author
of numerous white papers published on MSDN. He is also the author of a book titled
Inside MOSS 2007, published by Microsoft Press. More information about Patrick can be found at his
blog.

 

Development Tools and Techniques for Working with Code in Windows SharePoint Services
3.0 (Part 2 of 2)

Patrick Tisseghem blog

Windows SharePoint Services Developer Center

SharePoint Server Developer Portal