[原文发表地址] Creating your first TFS Build Process for SharePoint projects (Chris O’Brien)
[原文发表时间] 2011-08-25 07:03
你配置了TFS 2010生成之后，你就可以创建一个生成定义来自动构建你的SharePoint代码库了。MSDN上有详细讲述这个方面的内容（参见Visual Studio应用周期管理中的 定义生成过程这部分），而这篇博文则会对构建SharePoint项目所需的特定要求做些指导，给在这方面刚开始的同行们强调一些关键信息。
以下是我们将在这篇博文中讨论的内容概述：
- 配置生成服务器来编译SharePoint程序集
- 配置生成服务器来生成SharePoint方案（WAP）包，不仅仅是程序集
- 创建首个生成定义——过程概述
- 编辑生成工作流
- 处理项目间的依赖关系
配置生成服务器以编译SharePoint程序集
根据默认设置，TFS 2010生成代理无法编译SharePoint代码。这是因为这些项目与SharePoint程序集（比如Microsoft.Sharepoint.dll）相关，而且这些程序集不常存在于生成服务器中，所以编译常常会失败。只有一种例外情况，那就是如果SharePoint 2010也直接安装在生成服务器上——介于性能关系，并不推荐这种布局。
要使编译成功，SharePoint程序集需复制到构建服务器上。这个过程在MSDN上有相关文件，微软也提供PowerShell脚本来“收集”SharePoint服务器中的程序集，然后在构建服务器上正确的文件系统位置“安装”它们。所以第一步就是：
1. 按照如何用TFS团队生成来构建SharePoint项目上的详细步骤
2. 使用在MSDN代码库中发布的SharePointProjectToTfsBuildServer.ps1PowerShell脚本（在上述文章中也有链接）
尽管PowerShell脚本多少简化了整个过程，但要注意除了那些默认收集的程序集之外，可能还会需要其他组件。而且，一些SharePoint程序集只能直接从SharePoint机器的GAC中复制（比如在GAC中导航到GAC_MSIL文件夹）。确切的程序集清单要根据你构建的代码而定。作为指南，我在对项目实行CI时，需要的程序集如下：
- Microsoft.Office.Server.dll
- Microsoft.Office.Server.UserProfiles.dll
- Microsoft.SharePoint.Client.dll
- Microsoft.SharePoint.Client.Runtime.dll
- Microsoft.SharePoint.Client.ServerRuntime.dll
- Microsoft.SharePoint.Linq.dll
- Microsoft.SharePoint.Portal.dll
- Microsoft.SharePoint.Publishing.dll
- Microsoft.SharePoint.Taxonomy.dll
- Microsoft.SharePoint.WorkflowActions.dll
- Microsoft.Web.CommandUI.dll
要添加程序集至PowerShell脚本，将37—41行的分配做如下变更：
|
Original script |
|
$Script:SharePoint14ReferenceAssemblies = @( |
|
编辑后 |
|
$Script:SharePoint14ReferenceAssemblies = @( |
注意偶尔你会发现添加新代码就意味着生成过程需要添加之前没有安装的其他的SharePoint程序集。
创建首个生成定义——过程概述
在TFS 2010中创建生成定义其实很简单。在这个部分，我们会涉及整个过程以及主要的配置步骤。我们最终会完成一个自动构建，即从最近签入代码中创建WSP，然后复制到下拉位置。在之后的博文中，我们还会展示如何在每次构建之后把WSP部署到SharePoint服务器上，包括引入程序集版本，自动测试等等。值得注意的是，即使是一个很简单的构建都可以使生成添加值布衣出现人为错误。有关实例之一就是在发布模式中生成程序集而非在调试模式中生成。我们现在来看看创建一个新生成定义的过程。（你可以去MSDN上的定义生成过程查看每个部分的详细介绍）。
1. 确保Visual Studio 2010连接上了TFS，然后在团队资源管理器中选择新构建定义，在构建上下文菜单中。
2. 为生成定义命名，并添加描述。
3. 在触发标签上，定义触发，比如构建在何时执行。触发是很重要的，在定义此项构建的类型时起了至关重要的作用。作为实例，你可以在CI触发上做一个简单的构建，日后再（长期）做些完善。大部分类型在意义上是明确的，不过有些不那么明显。详情参见特定生成触发及原因。
4. 工作区标签可以指定生成的工作地点。和开发者很像，构建过程对TFS源代码控制中的文件执行“获取最新”操作，这样就需要工作区的映射，确定文件系统中文件存储的位置。
设置工作区的时候，注意考虑以下几点：
- “获取最新”操作包括特定源代码控制文件夹中所有的文件夹和文件。如果你的构建只包括长列表中的一些Visual Studio项目，那构建就不需要整个源代码树了。指定下属文件夹的路径，只包含需要的项目会很高效，而且减少生成时间。
- $(SourceDir)标记对应构建代理的“工作目录”属性的目录（在TFS管理控制台进行配置）。
- 如果你改变了生成代理文件夹中特定的值，注意尽管浏览器对话框看上去是在本地主机上的，但路径使用的是在构建代理上的。因此，你需要自行输入路径而不是浏览位置。
- 为工作区选用较短路径。这是受Windows路径不能超过260个字符的限制，而且在构建工作目录中过多的字符对常规开发来说没有关系，但是涉及到自动构建工序的话，就会因此限制而失败。当然修改生成代理的工作目录的默认属性也可以起到一样的效果。
5. 在默认生成标签上，指定默认生成控制器（如果你有多个的话）和位置（Windows共享的文件夹），构建的结果会复制到这些位置。之后的系列中，我们会看到自动部署WSP文件，这个设置会用来复制包至用于测试的SharePoint环境。注意Windows共享（在下图中名为“BuildDrop”）必须存在，而且TFS构建和TFS服务账户必须有读/写许可。
6. 进程标签中可以完成许多重要的设置。这里，我们指定构建中的方案和项目，及使用的生成工作流（我们之后会进行更改），指定其它输入构建工作流的重要的参数。SharePoint生成的最重要的一个参数就是/p:IsPackaging=true值，它是输入MSBuild Arguments域的参数。这个值会告诉生成进程要实现SharePoint工具生成WSP包，就像Visual Studio 2010那样。如果这个遗漏了，那你的生成输出就会只有程序集了。
说到选择需要生成的Visual Studio项目和方案，你要考虑项目间的依赖，在自动生成中仔细地管理。参见之后的“依赖和引用的注意事项”。要查看进程标签上可用的其它设置，请查看MSDN上的使用默认模板定义生成。
7. 保留策略标签是用来指定生成保留的时长的。我们无需在这里改变什么，但是了解一下选项还是很有用的。因为在一段时间里发生很多个构建很常见（比如如果触发是“Continuous Integration”的话每一次签入就会引发一次生成），TFS会自动管理这些，所以它们不会永远累积起来。作为默认设置，最近的10个构建会为输出类型保留。
8. 保存生成定义。
9. 完成了初始生成定义之后，可以通过启动一个手动生成来进行测试。右击团队资源管理器中的生成定义，选择排序新生成
10. 生成现在就会运行并在构建资源管理器窗口中显示（会自动打开）。
11. 生成完成之后，双击列表中的项来显示生成总结。点击导航框中的查看日志链接显示详细的日志，如下图所示。
如果下拉位置的Windows共享配置适合（在第5部中详细介绍过），由构建生成的文件现在就会出现了。假设你将客户端机器连接到这个位置，你可以点击生成报告上的打开下拉文件夹链接来打开Windows资源管理器。注意和生成项目相关的程序集也会在这里显示（查看Jeremy Jameson的文章了解如何解决这个）。在列表中，你还会看到程序集，还有从最近的代码中自动生成的WSP文件。
你现在可以为你的SharePoint项目进行自动生成。
编辑生成工作流的基本介绍
有了自定义生成定义，你就会想在一些点上编辑生成过程工作流。虽然通过编辑构建参数，可以改变生成的许多方面，但更多扩展的自定义内容需要对工作流进行改变——比如配置构建以部署WSP包。
在这部分，我们会介绍一些基本的内容，向你展示如何变更简单的工作流。在之后的文章里，我们会介绍具体的变更，设计程序集版本和WSP包部署。
构建工作流原理
MSDN上的开发自定义生成过程中有详尽综合的自定义构建工作流内容，这个话题也在Visual Studio ALM Ranger团队的构建自定义指南中有出色的解释。不过在这里，我们先来了解一些核心的细节：
- 在TFS 2010 生成中，生成过程以.NET Framework 4工作流形式施行。要编辑工作流就需要在开发机器上安装.NETFramework 4。
- 生成工作流储存在TFS源代码控制中。使用的是定义中最近签入的版本。
- TFS 2010与一些样本生成工作流相连。这些可以使用或者复制，修改来生成自定义过程。这些工作流包括：
- DefaultTemplate.xaml –对大部分需求来说最好的起始点。
- LabDefaultTemplate.xaml – 通过微软系统中心虚拟机器管理器来支持管理实验环境（比如虚拟机器，片段）。
- UpgradeTemplate.xaml – 无需重新建造就能使用现有的TFS 2008构建工序（在MSBuild中写入）。
正如.NET Framework 4中的工作流一样，生成工作流是一系列执行实际工作的工作流内容。TFS 2010联系了许多与构建相关的内容，在自定义工作流时很有用。下表列出了在启动自定义生成时常见的重要内容。
|
Activity |
Purpose |
|
Used to call an external process e.g. a PowerShell script or .exe. |
|
|
Used to write messages of varying severities to the build log. |
|
|
Used to get the file system path from the path in TFS source control, or vice-versa. |
还需注意的是一些在System.Workflow.Activities中遗留的.NET Framework4的内容，比如SequenceActivity和IfElseActivity，能帮你在工作流中施行一些分支逻辑。
自定义生成工作流
这部分会介绍自定义工作流的过程。我们推荐对相连的工作流做备份，并进行修改，让原始工作流为其它生成和引用工作。Visual Studio中的对话会帮你完成这个过程。
1. 辨识相连的满足你需求的最佳启动工作流点（通常是DefaultTemplate.xaml）。
2. 在生成定义进程标签中，点击新按钮，开始复制现有定义。
3. 在出现的对话框中，确保选择了复制现有XAML文件，并且复制的文件是DefaultTemplate.xaml。给新文件做合适的命名，点击确认。
4. 点击确认后，你可以点击 连接至源代码控制资源管理器位置文本下的链接，跳转到那里之后，在开发者机器上执行“获取最新”，转至工作区。
5. 双击XAML文件，在工作流设计器中打开。打开工作流之后，导航至进程→序列→在代理上运行→初始化工作区位置。（如果从未接触过编辑工作流，可以参见在复杂的Windows工作流中导航）。确保在Visual Studio中工具盒窗口可见，从工具盒Team Foundation Build Activities中拖出WriteBuildWarning行为。（注意我们使用的是警告而不是标准消息内容，因为消息的严重性相对较低，默认情况下不会显示在生成报告中。）确保WriteBuildWarning行为是“初始化工作区”序列中的最后一个：
6. 通过指定消息编写构建日志来配置消息信息。在属性窗口中，找到消息属性，点击省略号（…）打开表达编辑窗口。输入字符串信息——在我的例子中，我使用的是“我们可以执行程序集版本。”之后的博文中我们会这么介绍。
7. 点击确定，然后保存工作流，签入。
8. 手动触发一个生成来测试工作流（使用“排序一个新生成”，就跟我们之前做的一样。）如果变更很成功，除了编译指定的项目和方案，你可以注意一下下列生成报告中的消息：
现在你已经测试了自定义生成工作流。我们要在这个基础上自动部署WSP到SharePoint服务器，这会在之后的系列博文中进行介绍。
关于依赖和引用的注意事项
许多开发者都很熟悉在引用其他程序集时文件和项目相关的区别。对自动生成来说，用项目引用是最简单的方法。这是因为生成顺序是自动评估的，依赖程序集在需要的时候确保构建。这意味着方案和项目签入TFS，在构建项参数中的选择应该设置为选用项目引用。一个好的方法就是将相关项目组成一组放入方案（在依赖间做项目引用），然后在构建项对话框中选择不同的方案。即使在许多项目引用一个“核心”项目时，相比在自动生成中管理文件引用的复杂性，也可以允许在许多方案中存在核心项目。
总结
在这篇文章中，我们从在TFS生成服务器中构建SharePoint项目开始。然后，我们创建了一个新的生成定义（基于与TFS相连的默认生成工作流），这是执行自动生成的基础。我们进一步创建了自定义生成工作流（从复制相连工作流开始），然后引入了编辑工作流的过程。这是我们之后要做更多的变更的基础，比如部署WSP，执行程序集版本，运行编码UI测试等。下一篇博文中我们会涉及这些。
Not logged in 
vbcti