使用.NET和Vss进行团队开发
使用Visual Studio®.NET和Visual SourceSafeTM进行团队开发
Visual Studio Enterprise Templates
至少为.NET Development工程创建一个新的数据库
BuildIt——Visual Studio .NET的一个自动编译连接工具
我是否需要在运行BuildIt之前安装Visual Studio？
绪言
本手册提供指导和建议，使您能够成功地建立一个团队开发环境并且工作于其中。
如果您正要开始一个.NET团队开发项目，首先需要了解在一个团队开发环境中如何完成开发过程。需要知道如何设置并且使用Microsoft® Visual Studio® .NET集成开发环境（IDE）提供的团队开发特性，并且还需要掌握相关开发技巧（例如如何正确地设置组件引用），开发团队成员们将遵循这些技巧以保证团队工作能顺利开展。
本手册分成以下几个章节：
l 第一章，“介绍团队环境”。本章节提供了对团队环境的一个整体概述并且介绍了关键的编译连接模块和过程。阅读本章节能够大致了解本手册的范围，并且理解本文档所基于的团队开发模型。
l 第二章，“ASP.NET网络应用软件开发模型”。本章节描述了在团队开发环境中构建网络应用软件应该采取的方法。
l 第三章，“构造解决方案和项目”。本章节解释了应该如何组织和构造Visual Studio .NET解决方案和项目，并且在“单解决方案”开发模型和“多解决方案”开发模型之间作出权衡。它同时也对您用于存储本地项目文件以及Microsoft Visual SourceSafe™ (VSS)下的文件夹结构作出建议。
l 第四章，“管理依存关系”。本章节解释了如何处理组件引用、网络引用、数据库引用和COM组件引用。
l 第五章，“创建过程”。本章节描述了创建过程、创建服务器所起的作用以及用于生成系统编译连接结果的自动编译连接脚本。
l 第六章，“使用Visual SourceSafe™”。本章节提供了一系列步骤，引领您完成一些通用的开发任务，例如如何向Visual SourceSafe中添加解决方案和项目，如何从VSS中获取解决方案，以及日常操作中如何登记和调出文件等。本章节使您快速掌握一些基本任务。
l 第七章，“建立和维护团队环境”。本章节描述了团队环境的基础架构以及环境中工作站和服务器所要求的硬件和软件配置。它同时也提供了如何创建和维护一个VSS数据库的指导。
如果希望能从本手册中得到尽可能多的信息，请按顺序通读本手册的所有章节。
谁需要阅读本手册
本手册为开发团队的领导者、普通开发人员、测试团队成员和系统管理员提供指导。如果您计划或者是正在开发一个基于团队的.NET开发项目，请阅读本手册。
您需要知道什么
要想使用本手册去建立一个适用于.NET的团队开发环境和开发过程，需要有一些使用Visual Studio .NET进行开发的经验。本手册假设您曾经创建.NET组件和网络服务，或者至少是熟悉它们。
您也应当知道在基于团队的软件开发项目中一直存在的普遍问题和当前面临的挑战。如果有使用源代码控制系统尤其是VSS进行开发的经验那就更好了。
注意：本手册主要说明作为源代码控制系统的VSS 6.0c版本（此版本封装在Visual Studio.NET中）的使用。然而，本手册的多数内容和其中所讨论的许多过程同样也适用于其它改动过的管理系统，它们中的许多还可以直接集成到Visual Studio .NET集成开发环境（IDE）当中。
术语
“系统”、“解决方案”和“项目”这些词汇将在本手册中广泛使用，可能造成沉重的阅读负担。以下部分说明了在本手册中使用这些词汇的上下文。
系统
词汇“系统”指的是您正在开发的整个应用软件。系统最终由发布到一个产品环境中的所有不同组合的组件组成。
内部系统和外部系统的分界线
本手册同时也引入了内部系统和外部系统分界线的概念。当开始考虑系统中的哪些组件将在中央编译连接过程中进行编译连接，哪些组件则落到了编译连接过程的范围之外，而仅仅被当作外部依存关系加以引用时，这种区分变得非常重要。以下文字对系统分界线作出了描述：
l 内部系统组件被作为系统编译连接过程的一部分进行编译连接。
l 外部系统组件是其它所有组件，包括第三方组件和.NET框架组件。
图1说明了内部系统和外部系统分界线的概念。
图1 内部系统和外部系统分界线
解决方案
如果您是Visual Studio .NET的入门者，“解决方案”对您来说也是新的词汇。一个解决方案本质上代表了正在从事的所有工作。Visual Studio .NET使用解决方案作为单个项目的容纳体——这些产生了您的系统组件（.NET组件）。解决方案文件维护了项目的依存关系信息，主要用于控制编译连接过程。解决方案在第三章——“构造解决方案和项目”的“Visual Studio .NET解决方案”中有更进一步讨论。
项目
在本手册的上下文中，有三种类型的项目：
l 一般开发项目。词汇“项目”在它最宽松的语义中指的是开发团队当前所做的工作。
l Visual Studio .NET项目。项目文件被Visual Studio .NET用作与个体组件相关的配置设置项的容纳体。这在第三章——“构造解决方案和项目”的“Visual Studio .NET项目”中有更进一步讨论。
l Visual SourceSafe项目。VSS数据库中的一个项目仅仅是文件（通常是逻辑相关）的集合体。一个VSS项目类似于一个附加了版本控制支持的操作系统文件夹。
第一章 介绍团队环境
许多元素、过程和任务组合在一起，使得基于团队的软件开发项目变为可能。本文档主要说明了两个核心过程：
● 开发过程
● 编译连接过程
虽然这是两个独立的过程，但是它们共享许多东西，因此，开发在两种场合下都适用工作惯例和项目结构是非常必要的。
团队开发环境如图1.1所示。图的阴影部分说明了本文档所定位的区域。请仔细研读这个图表，因为它定义了本文档的剩余章节的工作模型。
图1.1 团队开发环境
团队开发服务器和工作站
图1.1中关键服务器和工作站的任务和职责将在下面的部分中加以说明。其它基本服务器，例如备份服务器，出于简洁的目的在图中不作标示。如果想得到关于团队环境的基础架构的详细信息，包括硬件和软件需求，请参阅第七章——“建立和维护团队环境”。
VSS服务器
这是一个中心服务器，驻留了一个或多个用于为项目源文件提供版本控制访问的微软Visual SourceSafe (VSS)数据库。作为一个开发人员，您在微软Visual Studio®.NET的集成开发环境（IDE）中进行登记和调出文件的日常操作时，需要与之发生交互。它也能被编译连接脚本所访问，以获得编译连接当前系统所需的最新的源代码。
更多信息
关于VSS项目应该如何构造的信息，请参阅第三章——“构造解决方案和项目”中的“在解决方案和项目中使用一个统一的文件夹结构”。
关于更多如何配置VSS服务器的信息，请参阅第七章——“建立和维护团队环境”中的“安装和管理VSS”。
构建服务器
此服务器上运行的一个自动编译连接脚本被用来编译和连接您的整个系统。编译连接脚本对于所有的软件开发项目而言都是一个关键因素。它允许以一种自动的、一致的、可重复的方式生成您的系统的一系列连续版本。编译连接过程生成的输出组件在此服务器的文件夹中得以维护。
更多信息
有关引用外部组件的更多信息，请参考第四章——“管理依存关系”中的“引用组件”。
有关编译连接过程的更多信息，请参阅第五章——“创建过程”。
开发工作站
所有工作站必须以一种相似的方式进行配置。这包括了Visual Studio .NET集成开发环境的安装和配置。企业模板能够帮助您完成这项工作。
更多信息
关于使用企业模板的好处，请参阅第七章——“建立和维护团队环境”中的“Visual Studio企业模板”。
数据库服务器
这些服务器上驻留了微软SQL Server™对象，并提供了一个中心区域，开发人员能够连接位于其上的数据库，这些数据库的模式符合当前的系统数据库设计。在一些场合中，您也需要开发工作站上的本地SOL Server数据库能够提供独立的单元测试。例如，本地服务器允许您管理当前的一组测试数据，并且当您在操作这些数据时，不会影响其他团队成员。
更多信息
关于在团队环境中使用数据库的更多信息，请参阅第四章——“管理依存关系”中的“数据库开发”。
关于如何在一个团队环境中灵活管理连接串的更多信息，请参阅第四章——“管理依存关系”中的“引用数据库”。
Web服务器
团队环境中Web服务器的主要功能是驻留当前出于开发过程中的可扩展置标语言（XML）网络服务。当负责网络服务的开发团队在他们的本地工作站上使用微软Internet信息服务（IIS）开发这些服务时，可以在中央Web服务器上发布这些服务，使得其他开发人员或团队能够从客户项目中加以引用。
更多信息
关于使用网络服务的更多信息，请参阅第四章——“管理依存关系”中的“引用网络服务”。
第二章 ASP.NET网络应用软件开发模型
本章节描述了在一个团队环境中应该如何进行网络应用软件的开发。它推荐使用网络开发的一个隔离模型，并且将此模型与其它可选择方案进行比较。
开发网络应用软件存在三种主要的模型：
● 隔离（推荐）
● 半隔离
● 不隔离
隔离模型
使用这种模型，您将在一个完全孤立的环境中，在自己的开发工作站上，使用自己的本地Web服务器（http://localhost）进行开发（编辑、调试并且运行）。对主要的源文件的访问通过一个位于网络文件共享中的微软Visual SourceSafe™ (VSS)数据库加以控制。您可以选择允许或是不允许开发人员同时调出相同的文件。关于更多的信息，请参阅第六章——“使用Visual SourceSafe™”中的“多重调出”。
半隔离模型
使用这种模型，您将使用一个公共的Web服务器（http://remoteserver）进行应用软件开发和调试。通过一个位于网络文件共享中的VSS数据库进行文件的登记和调出。您正在工作的项目拷贝位于公共Web服务器上的一个特定的项目文件夹当中，这也是一个微软Internet信息服务（IIS）的虚拟根区。每一个开发人员在这个公共Web服务器上有一个唯一的文件夹。
注意：当第一次从VSS处获取一个网络项目时，微软Visual Studio®.NET不允许将工作文件放置在一个已经包含其它网络项目的文件夹当中。
如果VSS多重调出功能被使能的话，开发人员能够同时调出并且编辑同一个文件，但是只有一个开发人员能够于任意时间在Web服务器上对应用软件进行调试。这是因为当您调试一个应用软件时，IIS是处于阻塞状态的。这就阻止了服务器为来自其它应用软件的网络请求提供服务。
不隔离模型
使用这个模型，您也将使用一个公共的Web服务器（http://remoteserver）进行应用软件的开发和调试。然而，在服务器上将不会拥有自己的工作拷贝文件，并且所有开发人员使用一个统一的文件夹和虚拟根区，例如，http://remoteserver/projectname。
当保存一个文件的变化时，工作站上位于内存中的文件版本被使用超文本传输协议（HTTP）传送到服务器上。这将覆盖服务器上的已有拷贝。随后在您使用集成的源代码控制服务去登记所作的更改时，微软FrontPage扩展名被用于更新文件在一个VSS数据库中的主拷贝。
此三种模型如图2.1所示。
图2.1 网络开发模型
使用隔离开发模型
强烈推荐在团队开发中采用隔离开发模型，因为它提供了许多重大的优点。
隔离开发的优点
采用隔离开发模型能够提供以下优点：
● 您和团队成员伙伴能够彼此独立地使用网络应用软件的不同（本地）实例进行开发。
● 能够同时开发和调试应用软件，避免在不经意中干扰了其它成员的工作。
● 它提供了对源码控制的高级支持（与使用FrontPage扩展名的不隔离模型相比）。
● 它在一个局域网（LAN）环境中能略为快速地运行（与FrontPage扩展名相比）。
避免采用半隔离和不隔离开发模型
在团队开发环境中使用半隔离和不隔离模型是困难的。这些应该尽可能避免使用。
使用半隔离和不隔离模型的缺点
使用半隔离和不隔离模型有着以下缺点：
● 非常容易在无意间干扰其它开发人员。例如，在调试一个应用软件时，调试进程将锁定公共服务器，因此会对团队的其它成员造成影响。
● 在一个不隔离模型中，开发人员也能互相影响，因为每个网络应用软件中动态连接库的背后只存在一个唯一的代码。
● FrontPage扩展名（没有VSS集成）仅提供有限的源码控制能力。使用不隔离开发模型。所有的开发人员使用同一个位于Web服务器上的主拷贝。FrontPage扩展名的源码控制能力提供了一个“最后登记的有效”的开发模型。如果用户A和B同时调出相同的文件，用户A作出改变并加以存储，接着用户B也存储所作的变化，那么用户A所作的更改就会丢失。
一个不得不采用半隔离模型和不隔离模型的场合是，您的网络应用软件所需的特定资源只能通过公共Web服务器取得。您在使用微软.NET通行证进行开发时可能会遇到这样的情形。
如果不得不采用FrontPage扩展名，可以配置Visual Studio .NET在所有新的网络项目中都使用这个操作模式，并且能够在现有的网络项目中改变这个模式。
Ø 配置Visual Studio .NET以使用FrontPage扩展名
1. 在Tools菜单上, 点击Options。
2. 点击项目文件夹。
3. 在项目文件夹中，点击Web Settings.
4. 在右边的面板当中，选择FrontPage Extensions选项。
5. 点击OK接受改变。
Ø 要改变现有网络项目的访问模式
1. 在解决方案浏览器里右击项目，然后点击Properties。
2. 展开公共属性文件夹，然后点击Web Settings。
3. 改变Web Access Mode设置项。
4. 点击OK接受改变。
更多信息
关于在Visual Studio.NET中开发源码控制网络项目的更多信息，请参阅http://msdn.microsoft.com/library/en-us/dv_vstechart/html/vetchWebProjectsSourceControlIntegrationInVisualStudioNET.asp，“Visual Studio.NET中的网络项目和源码控制集成”。
第三章 构造解决方案和项目
为了保证开发和构建过程能够在一个团队环境中有效进行，最重要的是以一个正确的项目结构为开端，该结构在您所有的开发工作站和编译连接服务器上都是统一的。
本章节提供以下方面的指导：
● 划分微软Visual Studio .NET解决方案和项目。
● 管理本地文件系统和微软Visual SourceSafe（VSS）文件夹结构。
● 对于项目、组件和域名空间采用一定的命名规则。
Visual Studio .NET解决方案和项目
在讨论如何组织Visual Studio .NET解决方案和项目之前，非常重要的事情是需要了解它们的基本原理并且懂得它们是如何为本地以及源码控制提供者——通常是VSS所管理的。
如果已经熟悉Visual Studio .NET中的解决方案和项目，并且了解组成一个项目的各种文件类型，那么可以跳过本节，直接阅读“始终使用Visual Studio .NET进行源码控制操作”。
Visual Studio .NET项目
Visual Studio .NET使用项目文件作为所有编译连接和配置设置项的容纳体，这些设置项被用来生成一个.NET组件。项目文件的文件扩展名是.csproj或者.vbproj，取决于项目使用的语言。存在着许多不同的项目类型[以及相关的快速应用开发（RAD）模板]，尽管这些项目类型能够大体上被分成两类。这两种文件类型是：
● 网络项目。一个网络项目是使用超文本传输协议（HTTP）地址创建的项目（例如：http://localhost/MyWebProject）。网络项目包括用于向网络浏览器传送内容的ASP.NET网络应用软件和主要用于Internet上的数据集成的ASP.NET网络服务。
● 非网络或本地项目。非网络或本地项目是使用文件系统地址创建的项目（例如，C:\Projects\MySystem\MySolution\MyWinProject）。最普遍的本地项目类型是Windows应用软件和类库，尽管也有许多其它的类型，包括服务、控制台应用软件、数据库项目等等。
Visual Studio .NET解决方案
解决方案文件（有.sln的扩展文件名）被用来将相关项目组合在一起，并主要是被用来控制编译连接过程。您能够使用解决方案去控制编译连接的依存关系问题，并且控制所包含的项目被编译连接的精确顺序。
重要提示：一个项目可以是一个或多个解决方案的组成部分，但是一个解决方案不能被包括在其它解决方案当中。
图3.1说明了项目和解决方案之间的关系，同时也指出了VSS用于维护解决方案和项目层次的设置项的文件类型。
图3.1 Visual Studio .NET项目和解决方案
解决方案和编译连接依存关系
解决方案文件也包含了编译连接过程所使用的项目依存关系信息。例如，在前面的图中，依存关系信息指出项目A依赖于项目B，并且项目B依赖于项目C。因此，构建的顺序一定先是项目C，然后是项目B，最后才是项目A。当项目引用用于一个单个的解决方案时，Visual Studio .NET能够确保正确的编译连接顺序。
重要提示：存在两种基本类型的引用——项目引用和文件应用。您可以在Visual Studio .NET的Add References对话框中设置这两种引用。因为项目引用同时也建立编译连接顺序的依存关系，因此您也应当尽可能使用项目连接。关于更多的信息，请参阅第四章——“管理依存关系”中的“引用组件”。
服从源码控制的文件
以下的列表列出一些关键的文件类型。当一个解决方案在Visual Studio .NET集成开发环境（IDE）中被添加到源码控制中时，这些文件类型能够自动添加到VSS中。
● 解决方案文件（*.sln）。这些文件中所维护的关键条目包括了一个组成项目、依存关系信息、编译连接配置细节信息以及源码控制提供者细节的列表。
● 项目文件（*.csproj or *.vbproj）。这些文件中维护的关键条目包括组件编译连接设置项、引用的组件（通过名字和路径）以及一个文件清单。
● 应用软件配置文件。这些是基于可扩展置标语言（XML）的配置文件，用于控制项目运行期行为的不同侧面。
注意：对于网络应用软件，源码控制配置文件被称为Web.config。对于非网络应用软件，源码控制文件被称为app.config，并且被包含在项目文件夹里。在运行期间，Visual Studio .NET编译连接系统将app.config文件拷贝到Bin文件夹，并且将其重命名为Yourappname.exe.config。
对于非网络应用软件，一个配置文件是不会自动添加到一个新的项目当中的。如果您需要一个配置文件，就请手动加入。请确保它的文件名叫作app.config，并且将它放置到项目文件夹里。
● 源文件（*.cs、*.vb、*.aspx、*.asax、*.resx、*.vsdisco、*.css等等）。所有的项目源文件服从源码控制。
不服从源码控制的文件
以下的文件不能添加到源码控制中，因为它们是针对开发人员的：
● 解决方案用户选项文件（*.suo）。这些文件包括单个开发人员对集成开发环境所作的私人化的定制。
● 项目用户选项文件（*.csproj.user or *.vbproj.user）。这些文件包括开发人员特定的项目选项和一个可选的集成开发环境用来定位被引用组件的引用路径。第四章——“管理依存关系”中的“引用组件”一节解释了组件引用应该在一个团队环境中得到管理。
● 网络信息文件（*.csproj.webinfo or *.vbproj.webinfo）。这个文件跟踪记录一个项目的虚拟根区位置。这个文件不能添加到源码控制中，以便允许单个开发人员为他们各自的项目工作拷贝指定不同的虚拟根区。当这个能力存在的时候，您和所有的团队成员在开发网络应用软件时建议使用一个统一的（本地）虚拟根区位置。关于网络和非网络应用软件的推荐结构的进一步讨论，可以参阅“在解决方案和项目中使用一个统一的文件夹结构”一节。
● 编译连接输出包括组件的动态连接库（DLLs）、Interop组件动态连接库和可执行文件。然而，最好将项目引用的外部系统组件添加到VSS中，这些组件不作为系统的编译连接过程的一部分进行编译连接（例如第三方控件和库文件）。关于细节，请参阅第四章——“管理依存关系”中的“在项目中包含外部系统组件”。
始终使用Visual Studio .NET作源码控制操作
VSS中所有项目的创建和操作应当使用Visual Studio .NET中集成的VSS support菜单进行——而不要使用VSS浏览器。Visual Studio .NET的功能保证：
● 只将适当的文件添加到源码控制中。
● 您的Visual Studio .NET项目和解决方案文件被适当的VSS特定细节所更新。例如，Visual Studio .NET中的VSS功能在以下几个方面更新解决方案文件（.sln）文件：
1. 在一个解决方案当中，处于源码控制下的项目的个数（这个数目包括解决方案文件本身）。
2. 每个项目的VSS服务器。
3. 每个项目在服务器上的存放位置。
4. 每个项目的源代码控制提供者的名称。
5. 每个项目相对于解决方案文件的存放位置。
包含在解决方案用户文件（.suo）和项目文件（.csproj or .vbproj）中的其它文件也得到了更新。
重要提示：应当始终通过Visual Studio .NET接口而不是VSS浏览器与VSS进行交互。产品的紧密集成确保文件在一个团队环境中能够得到正确的管理。
划分解决方案和项目
用于划分解决方案和项目的方法将极大地影响您在团队环境中的开发成效和编译连接过程。
有三种模型可考虑用来划分解决方案和项目：
1. 单解决方案
2. 分块单解决方案
3. 多解决方案
重要提示：除非您有非常好的理由要使用一个多解决方案模型，否则请尽量避免使用，而应当采用一个单解决方案模型。或者在较大的系统中，您可以考虑采用分块单解决方案模型。后两者与多解决方案模型相比比较容易使用，而且提供了许多重要的优点，这在以后的章节中会有进一步的讨论。
尽可能使用单解决方案模型
使用单解决方案模型，可以创建一个单一的Visual Studio .NET解决方案，并且将其用作您的应用软件所定义的所有项目的容纳体。当使用一个单一解决方案模型时，请遵循以下几点：
● 如果一个项目需要引用另外一个项目生成的组件，请使用项目引用。
● 文件引用只在引用外部系统组件（例如.NET框架组件和第三方组件）时使用，这些组件不会被编译连接到您的系统的剩余部分当中。
图3.2 单解决方案模型
应当尽可能使用单解决方案模型，因为它能提供许多重大的优点。
优点
单解决方案模型提供了以下优点：
● 当需要引用由一个独立项目生成的其它组件时，可以使用项目引用。项目引用是对其它组件进行引用的首先方式，它确保这些组件能在团队环境中的所有开发工作站上工作。项目引用的众多优点和关于何时使用文件引用的讨论请参见第四章——“管理依存关系”中的“引用组件”。
● 避免了组件版本问题，因为Visual Studio .NET能够检测在何时引用组件的客户需要重新编译连接。
● 项目引用对被引用的项目的配置变化非常敏感。这意味着您能够在项目中自动从调试编译连接切换到发布编译连接，而无需重新设置引用。
● 系统编译连接过程和编译连接脚本变得更加简单。
缺点
应当尽可能地采用单解决方案模型，然而：
● 模型的伸缩性有限。如果您想在解决方案中的某个项目上开展工作，您就不得不获得这个解决方案中所有项目的源代码。
● 即使是对单个项目中的单个源文件所作的最小改变都将导致这个解决方案中的许多项目必须根据项目间的依存关系重新进行编译连接。如果一个被引用的项目的组件接口发生了变化，您将必须重新编译连接客户项目。然而，不必要的重新编译连接工作将会非常浪费时间，尤其是对于包含了许多项目的解决方案而言。
对于较大的系统，考虑使用分块单解决方案模型
对于较大的系统，如果想减少每个开发工作站所需要的项目和源文件的数量，可以考虑将一些彼此独立的解决方案文件中的相关项目组合在一起。这允许您和开发成员伙伴在内部系统边界以内针对一些独立的、较小的子系统分别开展工作。
注意：一个单一的项目文件能够包含在一个或多个解决方案文件中，但是解决方案不能包含在另外的解决方案当中。
图3.3 分块单解决方案模型
图3.3例示了分块单模型解决方案。请注意如何使用独立解决方案的文件，以便使您可以工作在内部系统边界以内的较小的子系统上。同时还要注意这样的操作如何导致项目被包含在多于一个的解决方案文件当中。例如，项目D和H总共位于包括主解决方案在内的三个解决方案文件当中。
在分块单模型解决方案中：
● 所有的项目包含在一个主解决方案当中。这被系统编译连接过程用来重新编译连接整个系统。如果需要工作在项目文件的顶层，那么也需要工作在主解决方案的层次上。
● 项目引用在单个项目之间使用。
● 独立解决方案文件为选定的项目文件所引入。如果愿意，可以为系统中的每一个项目引入一个解决方案文件。每个解决方案文件包含了主项目文件、它所依赖的任何下位项目以及在依存关系链表中它所依赖的更多项目。
● 独立的解决方案文件允许您工作在整个系统内部的较小的子系统上，但是保留了项目引用的重大好处。在每一个解决方案文件当中，项目引用被用于方案的组成项目当中。
注意：您不应该将两个互相引用的项目分割到不同的解决方案当中，因为这将使得文件引用的使用变得必要，而文件引用是应当尽可能避免的。关于更多信息，请参阅第四章——“管理依存关系”中的“引用组件”。
优点
分块单解决方案模型提供了以下一些优势：
● 能够工作在小的子系统上。不需要在每一个开发工作站上都拥有整个系统的源代码和项目文件。因此，Visual Studio .NET中的解决方案浏览器变得不再混乱并且容易使用。
● 能够在每个解决方案当中使用项目引用。
● 主解决方案允许您更容易地重新编译连接整个系统。主解决方案文件可为编译连接服务器上的编译连接过程所使用。
缺点
分块单解决方案模型也存在以下一些缺点：
● 当添加新的项目时，必须潜在地添加它们并且在多个解决方案文件中更新所有的项目引用；例如，主解决方案文件和一个或多个其它的解决方案文件。
● 会被划分系统的方式所限定。这是受项目依存关系所决定的。因此，如果工作在顶层项目当中，例如，表达层中的一个ASP.NET网络应用软件，不得不把所有相关的项目拷贝到开发工作站上。这就可能包含了您的企业和数据层次的项目。另外，如果工作在类库或者是数据访问组件的开发过程中，仅仅需要那些单个的项目。
仅在绝对必要的情况下使用多解决方案模型
多解决方案模型类似于分块单解决方案模型，除了以下不同：
● 不存在主解决方案文件。
● 文件引用使用在独立解决方案的项目之间（尽管项目引用仍然用于单个解决方案的项目之间）。
● 运行在编译连接服务器上的系统编译连接脚本基于已知的依存关系依次编译连接每个解决方案。编译连接脚本将输出组件放置在编译连接服务器上的一个固定位置上。
n 多解决方案模型如图3.4所示。
图3.4 多解决方案模型
优点
多解决方案模型提供了一些分块单解决方案模型所不具备的优点：
● 每个项目仅仅包含在一个单一的解决方案当中。这意味着从系统中增加和删除项目变得更加容易。
● 能够将系统基于逻辑界线细分为多个解决方案，并且不再受到项目依存关系的驱使。例如，可以基于企业功能的不同区域作出划分。
缺点
多解决方案有以下一些缺点：
● 当需要引用一个由另一个独立解决方案所产生的组件时，将不得不使用文件引用。文件引用（不像项目应用）不会自动建立编译连接依存关系。这就意味着必须在系统编译连接脚本中解决关于解决方案的编译连接顺序问题。虽然这是可以被管理的，但是它增加了编译连接过程的复杂性。
● 也不得不引用一个动态连接库（DLL）的特定配置的编译连接结果（例如，发布或是调试版本）。项目引用能对其进行自动管理并且在Visual Studio .NET中引用当前激活的配置。
● 当工作在单个解决方案当中时，您能够得到其它团队成员开发的最新代码（或许在其它项目当中），以进行本地集成测试。能保证在将自己的代码登记到VSS当中，准备下一次系统编译连接之前，一切都不会出现问题。在一个多解决方案系统中，这样做要困难得多，因您仅仅能够在使用以前的系统编译连接结果的前提下测试您的解决方案。
您应当能够很容易地在一个包含10、20甚至是30个项目的系统中使用单解决方案。一个解决方案中，最大的可工作项目的数量很难得到精确的定义，因为它依赖于特定的编译连接服务器和开发工作站，以及和单个项目有关的源文件的数量和大小。
考虑将项目组合成解决方案
解决将项目组合成解决方案的问题的最好方法是考虑您的应用软件的总体结构。例如：
● 从确定系统中的组成部件（或是组件）开始；这就定义了系统所要求的单个项目。记住，每一个组件都是由一个单独的Visual Studio .NET项目生成的。
● 瞄准单解决方案模型。如果想通过分割项目来提供更高层次的分散性和控制，可以使用分块单解决方案模型。考虑一下哪个组的项目是您想进行隔离工作的，例如，一组中间层次的商业组件，以及依靠这些组件创建的独立的解决方案。
如果将项目分割成了多个解决方案，并且利用分块单解决方案模型无法这样做时，请仔细考虑一下跨解决方案的依存关系，以及分隔开两个独立组件的接口的本质。当您将项目组织成独立的解决方案时，应当：
● 确定分隔系统的各个组成部分的外部接口。尽量去确定那些最不可能发生变化的接口。如果一个项目的外部接口经常发生变化，那么任意一个独立的项目在理论上都应当放置到同一个解决方案当中。
● 如果正在使用网络服务，以便将系统中的一些组件连接在一起，网络服务接口就提供了一个良好的分界线。例如，网络服务接口的客户端项目和服务器端项目可能成为独立解决方案的一部分。
在解决方案和项目中使用一个统一的文件夹结构
如果使用一个通用的结构用于存储Visual Studio .NET的解决方案和项目的话，在团队开发环境中进行的工作在整体上要变得容易得多。为了保持事物的对称性（这样做的结果是变得更简单），请在VSS中设置一个与您的本地文件系统结构相匹配的文件夹结构。
定义一个通用的根文件夹
在VSS中定义一个通用的根文件夹——例如，在您的文件系统中是C:\Projects，在VSS中是$/Projects。这将作为所有开发系统的容纳体。在这个通用的根文件夹下，分别为每一个系统建立一个系统根文件夹——例如，C:\Projects\MyCompanysInsuranceApp和$/Projects
/MyCompanysInsuranceApp。
在解决方案和项目中采用“父－子”文件夹结构
应当在解决方案和项目中采用一个“父－子”文件夹结构。
作到以下几点：
● 在系统根文件夹底下为您的Visual Studio .NET解决方案建立一个子文件夹。
● 在解决方案文件夹下为每个组成项目专门建立一个子文件夹。
● 在网络和非网络应用软件中采用这个通用的文件夹结构。
● 不要将Bin文件夹或其内容添加到VSS中。
注意：如果使用分块单解决方案模型，请将项目文件夹放置在包含主解决方案文件的文件夹下。对于每一个您创建的子解决方案，请直接从这个位置包含项目文件。
图3.5例示了推荐使用的文件夹结构。
图3.5 Visual Studio .NET和VSS文件夹结构
下面的子章节描述了如何使用Visual Studio .NET集成开发环境去为网络和非网络应用软件创建适当的结构。
如何创建一个新的ASP.NET网络项目
缺省情况下，当创建一个新的ASP.NET网络应用软件时，项目文件被放置到位于缺省网站（通常是\inetpub\wwwroot）下的一个推荐使用的虚拟根区中，并且相关的解决方案文件被放置到\My Documents\Visual Studio Projects文件夹下。这个缺省的安排在一个团队开发环境中是不够理想的，因为它打破了您的VSS项目和本地文件之间的对称结构。
以下的步骤指导您根据推荐的解决方案和项目文件夹结构去创建一个新的ASP.NET网络应用软件。这些步骤假定了一个被称为MyWebAppSolution的解决方案和一个被称为MyWebApp的项目。
如果将词汇Solution（或者Soln）包含在解决方案的名字当中，将有助于清楚地将其与项目文件名区分开来。
符合要求的结构如图3.6所示。注意那个项目文件夹和微软Internet信息服务（IIS）的虚拟根区是同一个东西。
图3.6 推荐使用的网络应用软件结构
Ø 要使用这个结构创建一个新的网络应用软件
1. 打开Visual Studio .NET，在File菜单上，指向New，接着点击Blank Solution。
2. 键入MyWebAppSolution作为解决方案名称，接着将它的位置设为\Projects\MySystem。
3. 点击OK. Visual Studio .NET在指定的根文件夹位置下创建MyWebAppSolution文件夹。
4. 使用Windows浏览器在\Projects\MySystem\MyWebAppSolution文件夹下创建一个新的称为MyWebApp 的子文件夹。
5. 使用Windows浏览器或者Internet服务管理器将MyWebApp文件夹设成IIS的虚拟根区。
注意：Visual Studio .NET要求虚拟根区的名字和文件夹名字相匹配。
6. 回到Visual Studio .NET中，在File菜单上，指向Add Project，并且点击New Project。
7. 添加一个ASP.NET网络应用软件项目。
8. 在Location域，键入http://localhost/MyWebApp，然后点击OK。项目和网络源文件将在指定的虚拟根区中创建。
如何将一个网络应用软件分割成多个项目
在某些情况下，您可能想将网络应用软件分成同一个解决方案中的多个项目文件，以方便团队开发。例如，如果拥有不同的团队负责同一个网络应用软件的不同部分，那么将应用软件分成多个项目是非常有用的。Visual Studio .NET本身就能支持这个功能，但是也能通过对虚拟根区进行一些手动操作来达到这个目的。
重要提示：一个单项目方案比较简单，因此只在绝对必要的情况下才将一个网络应用软件分割成多个项目——典型的情况是针对非常大的网络应用软件。
更多信息
有关更多创建子网络项目的详细信息，请参阅文章Q307467，“在团队开发环境中，如何从多个项目中创建一个ASP.NET应用软件”。此文章位于http://search.support.microsoft.com/上的微软知识库中。
使用ASP.NET后台编码文件
应当知道，当调出一个网络表格（aspx）文件或者一个后台编码文件（aspx.cs或aspx.vb）时，Visual Studio .NET自动调出所有的文件。这是在设计时就决定了的，因为用户接口的变化通常包括了后台编码文件中的部分代码的改变。例如，如果为一个网络表格增加一个新的控件，Visual Studio .NET自动在后台编码文件中为这个控件创建一个成员变量。
如何创建一个新的非网络项目
以下的步骤将指导您去创建一个新的非网络项目类型，例如一个基于Windows的应用软件或是控制台应用软件、一个类库或是一个服务。这些步骤假定了一个被称为MyWinAppSolution的解决方案和一个称为MyWinApp的项目。
符合要求的结构如图3.7所示。
图3.7 非网络项目推荐使用的项目结构
Ø 要使用这个结构去创建一个新的非网络应用软件
1. 打开Visual Studio .NET, 在File菜单上，指向New, 接着点击Project。
2. 选择适当的项目类型和模板。
3. 在Name域中键入项目名称（本例中是MyWinApp）。
4. 将Location域设为\Projects\MySystem。
5. 点击More按键。
6. 选中Create directory for solution复选框。这使得项目文件在解决方案文件夹下的一个项目子文件夹内被创建出来。
7. 在New Solution Name域中键入MyWinAppSolution。
8. 点击OK完成项目和解决方案创建过程。
关于如何向Visual SourceSafe添加新创建的项目和解决方案的信息，请参阅第六章——“使用Visual SourceSafe”中的“在VSS中登记新的解决方案”。
仔细考虑命名规则
在给项目、组件、文件夹以及域名空间进行命名之前，请仔细并且及早地考虑命名方式。虽然在开发周期中的迟些时候仍然能够对这些条款进行重命名，您还是应当尽量避免重命名情况的出现。有关如何重命名一个项目的更多信息，请参阅第六章——“使用Visual SourceSafe”。
您也应当使用一组一致的名称，因为这将极大地简化项目的组织工作。
有24个团队使用Visual Studio .NET和Visual SourceSafe进行开发。
在项目和组件中使用通用的名称
输出组件名称应当总是和生成它的项目名称相匹配。例如，应当能够假定一个被称为MyCompany.Utilities.Data.dll的组件由一个被称为MyCompany.Utilities.Data的项目生成。
如果改变了一个输出组件的名称，请考虑改变项目的名称以便使它们能够匹配，反之亦然。
使用一个通用的根域名空间名称
将类型（结构、类、接口等等）放置到其中的根域名空间应当和项目以及组件的名称相匹配。
例如，使用MyCompany.Utilities.Data作为MyCompany.Utilities.Data.dll组件的根域名空间。
虽然.NET不需要这种协定，但是它对同步的名称比较敏感，因为它能够据此来指出哪种类型存在于哪些组件当中。
注意：微软Visual Basic® .NET项目通过项目属性显示了根域名空间。缺省情况下，在Visual Basic项目中创建的类型被放置到这个域名空间当中。如果您在Visual Basic .NET项目中使用了明确的域名空间语句，就请删除根域名空间相应的条目，否则这个明确指定的域名空间名称将附加到根域名空间名称后面。
C#项目通过项目属性显示了一个缺省的域名空间属性。这被再次用于决定加入到项目中的新类型要被放置到哪个域名空间当中。然而，与Visual Basic .NET项目不同，根域名空间在您的源文件中是通过域名空间语句加以明确规定的。
在VSS和本地文件夹中使用通用的名称
就像之前提到的那样，应该使本地解决方案和项目文件夹名称和它们对应的VSS文件夹名称保持同步。
第四章 管理依存关系
本章节提供的信息帮助您：
● 在项目和解决方案之间管理依存关系和引用。
● 管理.NET组件、网络服务、数据库、服务组件和COM Interop库的依存关系。
需要一个统一的、可维护的方案去管理团队环境中的依存关系。依存关系随着时间不可避免地发生变化，也会因此影响到您的应用软件的编译连接过程（和编译连接顺序）。
例如，当一个依存关系发生改变时，客户组件必须重新编译连接以便跟最新的版本保持同步。取决于依存关系的类型和它被引用的方式，微软Visual Studio® .NET编译连接系统能够或者不能自动处理编译连接的顺序问题。
引用组件
当需要使用包含在另外一个组件中的一个类型（例如一个类或者是结构）时，必须设置一个到那个组件的引用。这就在客户组件的装载清单上创建了一个组件引用，而该清单确定了依存关系的名称和版本。Visual Studio .NET支持两种类型的引用：项目引用和文件引用。
使用项目引用
Visual Studio .NET中Add Reference对话框中的项目页列出了当前解决方案中的所有其它项目。这就允许您在同一个解决方案中创建一个指向其它项目的项目引用。项目应用是推荐使用的设置引用的方法，因为它提供了许多的优点。
注意：项目引用是应当尽可能采用一个单解决方案模型或分块单解决方案模型的主要原因。
项目引用的优点
使用项目引用的优点有：
● 它们工作在解决方案和项目集合被装载的开发工作站上。这是因为一个项目全局唯一标识符（GUID）被放置到项目文件当中，此标识符在当前解决方案的上下文中唯一标志了被引用的项目。
● 它们允许Visual Studio .NET编译连接系统跟踪项目依存关系的变化，并且决定正确的项目编译连接顺序。
● 它们避免了引用组件在一个特定的计算机上发生丢失的潜在可能。
● 它们自动跟踪项目配置的变化。例如，当使用一个调试配置进行编译连接时时，一个指向调试组件的项目引用由被引用项目生成，而在一个发布配置中，它们将指向发布组件。这就意味着能够在项目中自动地从调试编译连接切换到发布编译连接，而无需重新设置引用。
● 它们允许Visual Studio .NET检测并且阻止循环依存关系。
仅在必要的时候使用文件引用
如果因为需要引用一个当前解决方案的项目集合之外的外部组件，而不能使用项目引用时，必须设置一个文件引用。以下是设置一个文件引用的两种方法：
● 为了引用一个.NET框架组件，需要从Add References对话框的.NET标签所显示的列表中选择该组件。
● 可以使用Add References对话框的Browse按键。
如果设置了一个文件引用，通向该组件的路径将被保存在源码控制的项目文件当中。为本地组件保存一个相对路径，为基于服务器的组件保存一个完整的网络路径，这在下面的项目文件snippet得到了示范。请注意HintPath属性。
<References>
<Reference
Name = "System.XML"
AssemblyName = "System.Xml"
HintPath =
"..\..\..\..\WINDOWS\Microsoft.NET\Framework\v1.0.3423\System.XML.dll"
/>
<Reference
Name = "Lib1"
AssemblyName = "Lib1"
HintPath = "\\BuildServer\Latest\Release\SharedComponent\SomeControl.dll"
/>
</References>
注意：象System.XML.dll这样的组件被放置在全局组件缓存（GAC）中。然而，请不要在GAC中直接引用一个组件。一个可以代替的做法是，应当在Add References对话框的.NET标签上选择一个组件，这样实际上引用了这个组件的一个拷贝，该拷贝位于%windir%\Microsoft.NET\Framework\<version>\文件夹当中。
在项目和文件引用中使用Copy Local = True
每个引用都有一个相应的copy local特性。Visual Studio .NET在引用被初次加入的时候决定这个属性的初始设置（true或false）。如果被引用的组件被发现出于全局组件缓存当中，则这个值被设为false，否则，这个值被设为true。
不应当改变这个缺省设置。如果copy local设为true，在引用被设置的情况下，Visual Studio
.NET编译连接系统将拷贝任意一个被引用的组件（和其它相关联的下位组件）到客户项目的输出文件夹当中。
例如，如果您的客户项目引用了一个被称为Lib1的组件，并且Lib1依赖于Lib2和Lib3，那么Lib1、Lib2和Lib3将会被Visual Studio .NET在编译连接的时候自动拷贝到项目的本地输出文件夹当中。
依存关系自动跟踪
每次编译连接本地项目时，编译连接系统对被引用的组件文件和工作在您的开发工作站上的拷贝进行日期和时间的比较。如果引用的组件比较新，则这个新版本就被拷贝到本地文件夹当中。这个方案的一个好处是某个开发人员建立的一个项目引用不会锁定服务器上这个组件的动态连接库（DLL），并且不会以任何方式去干扰编译连接过程。
在单解决方案系统和分块单解决方案系统中使用文件引用
请尽可能使用项目引用，并且使文件引用的使用减少到最小。
如果采用单解决方案和分块单解决方案模型，那么仅在引用系统外部组件（也就是说，那些不为系统编译连接过程所编译连接的组件）时才需要使用文件引用。这些特定的组件包括：
1. 在Add References对话框的.NET标签中被引用的.NET框架组件。这在团队环境中不会引起问题，因为.NET框架组件位于所有开发工作站的一个共同位置上。
2. 使用Add References对话框的Browse按键引用的外部系统组件。这些包括第三方组件和在您的公司内部、当前系统的外部编译连接的组件。关于如何管理这种类型的外部系统组件，请参阅“在项目中包含外部系统组件”。
在多解决方案系统中使用文件引用
如果采用一个多解决方案模型，这将迫使您在多个场合下不得不使用文件引用——当引用一个在不同的解决方案中生成的组件时。
考虑引用位置
当不得不引用一个跨解决方案的组件时，有以下两个选择：
● 可以通过使用一个虚拟驱动器盘符或者通用命名规则（UNC）路径在编译连接服务器上引用一个组件。
● 可以将由编译连接服务器上的编译连接过程生成的一组组件拷贝到您的本地开发工作站上，然后使用一个虚拟驱动器盘符去建立一个本地引用。关于使用虚拟驱动器盘符的更多信息，请参阅“使用虚拟驱动器盘符以获得更大的灵活性”。
从编译连接服务器上引用组件的优点：
这个方案的优点是：
● 能够保证引用到特定组件的最新版本，因为编译连接过程周期性（例如，每天）地更新组件。
● 项目文件中包含虚拟驱动器盘符和UNC路径的路径能够在所有的开发工作站和编译连接服务器上工作。
从编译连接服务器上引用组件的缺点：
这个方案同时也有一些缺点，这些缺点在某些开发环境中可能显得比较重大（尤其是在大系统中）。以下是这个方案的一些缺点：
● 不能直接控制什么时候您引用的组件发生更新。因此，服务器上一个组件的新版本可能在一个不适当的时候打断您的本地编译连接过程，比如可能正处于开发和调试系统中另外一个区域的中间阶段。尽管中央编译连接过程通常在晚上运行，但是有时候，一些中间的编译连接工作需要在白天进行。这些中间编译连接工作可能引起潜在的问题。
● 这个方案不支持断开连接的情况下的开发。当编译连接一个引用编译连接服务器上的某个组件的本地项目时，必须拥有一个到编译连接服务器的直接连接。
考虑使用隔离开发方案
如果在开发工作中需要一个高级别的分散性，可以采用隔离开发方案。使用这个方案，需要：
1. 将编译连接服务器上的编译连接输出拷贝到您的开发工作站上的一个公共位置。这可以手动执行，也可以借助一个脚本文件进行。
2. 建立一个通用的虚拟驱动器（例如，驱动器R），这样所有的开发人员都可以使用相同的路径引用组件。
3. 使用虚拟驱动器盘符（驱动器R）去设置所有本地组件的引用。
4. 周期性地检查编译连接服务器上新的编译连接输出，并且在您方便的时候手动地拷贝到工作站上。
使用虚拟驱动器盘符以获得更大的灵活性
如果引用了一个从编译连接服务器上拷贝而来的本地组件，应当用subst命令，并且使用一个虚拟驱动器盘符去完成这样的操作。
重要提示：团队中的所有开发人员必须采用相同的驱动器盘符，因为它为源码控制项目文件所维护，就像下述代码所示范的那样。
<References>
<Reference
Name = "Lib1"
AssemblyName = "Lib1"
HintPath = "R:\Latest\Release\SharedComponent\SomeControl.dll"
/>
</References>
使用虚拟驱动器盘符的另外一个优点是，它允许您非常容易地将其重映射到一个不同的位置。例如，可能希望在大部分开发时间中将其映射到编译连接服务器上，但是当需要进行隔离开发的时候，可以重新将其映射到本地。
总是使用文件引用对发布编译连接进行引用
编译连接脚本周期性（典型的情况是每天）地更新编译连接服务器的当前组件。编译连接脚本通常生成组件的调试和发布版本。开发人员使用调试动态连接库，而测试者使用发布动态连接库，就像下面所说的那样：
● 作为一个开发人员，应当安装调试动态连接库去进行您的开发和单元测试工作。
● 测试团队的成员应当安装系统的发布版本，并且始终使用发布动态连接库进行测试。不要推迟发布编译连接的生成，除非产品的发布日期已经临近。因为发布版本有暴露出问题的潜在可能，而这些问题可能在调试编译连接中并不表现出来。
为了适应调试编译连接和发布编译连接的需要，编译连接脚本在编译连接服务器上将组件拷贝到发布和调试文件夹中。关于更详细的信息，请参阅第五章——“编译连接过程”。
作为一个开发人员，应当总是从发布文件夹中引用组件，原因如下：
● 这些组件代表了应用到生产中的相关组件的最终版本。
● 不需要为了生成发布编译连接而将文件引用从调试文件夹变为发布文件夹。文件引用不会象项目引用那样动态改变以跟踪配置变化。
使用引用路径以协助隔离开发和调试
引用发布组件的一个问题是您不能够调试并且进入组件内部。如果需要调试一个被引用的、包含在一个独立解决方案中的组件：
1. 将解决方案拷贝到您的开发工作站上。
2. 重新编译连接组件的调试版本。
3. 在客户项目中设置指向被引用组件的调试输出文件夹的引用路径。
4. 重新编译连接并且运行客户项目。这将导致被引用组件的本地调试版本被拷贝到客户项目的输出文件夹当中。接着可以调试并且进入被引用的组件。
5. 当完成调试，并且想回复到从组件的通常位置进行引用的情况时，请删除引用路径条目。
什么是引用路径？
引用路径是每个计算机、每个开发人员都有的设置项，在项目用户选项文件（*.csproj.user或*.vbproj.user）中被作为可扩展置标语言（XML）元素加以维护。它被Visual Studio .NET用来帮助在编译连接期间定位组件引用。
重要提示：如果您遵从先前的指导并且使用项目引用或是文件引用（使用虚拟驱动器）去引用组件，所有的引用都能被任意一台计算机上的Visual Studio .NET所解析，而且引用路径并不是时时必需的。然而，引用路径在某些场合中非常有用，因为它允许您覆盖源码控制项目文件中<HintPath>元素所维护的路径。
在编译连接期间解析组件引用
在编译连接期间，Visual Studio .NET通过搜索以下位置来解析组件引用，搜索的顺序依次为：
1. 在一个项目文件夹中查找组件。这假设您使用Add Existing Item菜单项将组件加入到了项目当中。项目文件夹包括解决方案浏览器所显示的任意一个文件夹（除非Show All Files正在起作用）
2. 在项目用户选项文件中的<Settings>元素的ReferencePath属性所列出的文件夹中进行查找。这个属性包含了一个以逗号分隔的文件夹列表。
3. 使用项目文件中的<HintPath>元素。
4. 在注册表设置项指定的一组文件夹中进行查找。这些文件夹包含了显示在Add references对话框的.NET标签中的组件。关于更详细的信息，请参阅“使用Add Reference对话框的.NET标签”。
5. 在项目文件夹下的obj子文件夹中查找COM Interop组件。关于更多信息，请参阅“引用COM对象”。
注意：项目用户选项文件中的引用路径在设置文件引用时要领先于提示路径。
进行隔离开发和单元测试
引用路径也能帮助您在多解决方案系统中进行隔离开发和单元测试。考虑解决方案SA和解决方案SB，SA中的一个项目PA依赖于SB中的一个库项目PB。如果想在下次系统编译连接之前对这两个解决方案进行一些隔离开发和单元测试，可以改变PA的引用路径，使其指向PB的输出文件夹。这将允许对PB作出改变，并且在本地重新编译连接PB，然后在SA中对其进行测试。
您能够这样做，而无需再次检查SB，并且等待下一个编译连接过程重新生成它的组件。
因为引用路径是项目用户选项文件（没有添加到源码控制中）当中每一个开发人员都拥有的设置项，所以当您下一次在VSS中登记这些解决方案时，不会影响编译连接过程或是其他开发伙伴。
如何为特定项目设置引用路径
使用以下步骤为一个特定项目设置引用路径属性。
Ø 要想更改一个特定项目的引用路径
1. 在解决方案浏览器中右击项目，然后点击Properties。
2. 展开Common Properties文件夹，然后点击Reference Path。
3. 对于C#项目，点击New Line图标，然后键入新的引用路径。或者，对于Visual Basic .NET项目，在Folder域中键入引用路径，然后点击Add Folder。
4. 点击OK关闭Properties对话框。
在项目中包含外部系统组件
处理外部系统组件（例如不被创建过程所重新编译连接的第三方网络控件或组件）的最好方法是直接在那些需要对它们进行引用的项目中直接包含这些组件。在概念上，以看待和.bmp或.gif文件的相同方式去看待外部系统组件。
Ø 要包含并且引用一个外部系统组件
1. 在解决方案浏览器中，右击需要引用这个组件的项目，然后点击Add Existing Item。
2. 浏览组件，然后点击OK。接着组件会被拷贝到项目文件夹下，并且自动添加到VSS当中（假设项目已经进行了源码控制）。
3. 使用Add Reference对话框的Browse按键去设置指向项目文件夹中的组件的文件应用。
优点
这个方案有两个优点：
● 外部系统组件与项目文件一起保持源码控制。当一个新版本的组件可用时，它的文件可以添加到VSS中作为一个新的文件，并且保有自己的文件历史。
● 最重要的是，整个系统被包含在VSS中；这包括了所有的外部系统组件，例如第三方控件。能够从VSS中得到系统早先的版本，包括所有的源代码和外部依存关系。这使您可以得到较早版本的系统的一个完整快照。
考虑在VSS中共享外部系统组件
如果一个特定的外部系统组件被多个项目加以引用，那么它要在每一个项目中都得到维护。这就使得更新组件到较高的版本成为一个更为困难的任务。
可以通过在使用这个组件的项目的VSS之间共享外部系统组件去解决这个问题。这允许文件在一个项目中进行更新。可以通过在解决方案浏览器中右击项目，然后点击Get Latest Version （Recursive）来刷新维护在其它项目中的拷贝。
使用Add Reference对话框中的.NET标签
Add Reference中的.NET标签显示了系统组件和与.NET框架及其它可选组件一并提供的主Interop组件。这些通常（但不是必要）是那些安装在全局组件缓存（GAC）中的组件。
可以使自己的组件出现在这个列表中，但是这需要对注册表作一个修改，以指定能包含您的组件的一个或多个文件夹。
例如，能够应用注册表更新，以指向包含您的编译连接脚本所编译生成的组件的文件夹（可以是本地的，也可以位于编译连接服务器上）。这允许开发人员从.NET标签中引用这些组件，避免了Browse按键的使用。
Ø 为了向.NET标签中加入您自己的组件
1. 在以下这些注册码的下面创建一个新的注册码（例如，InnerSystemAssemblies）：
HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\AssemblyFolders
HKEY_CURRENT_USER\Software\Microsoft\.NETFramework\AssemblyFolders
2. 将新的注册码的缺省值指向包含您的组件的文件夹。
3. 如果打开了Visual Studio .NET，必须将其关闭然后再次打开，以便使得所作的改变生效。
引用网络服务
在单解决方案系统中，所有的开发人员不再使用网络服务的本地工作拷贝，因为它们在单解决方案的项目中得到定义。当第一次从VSS打开一个解决方案时，所有的项目（包括任意一个网络服务）就被安装到本地。类似地，如果一个网络服务被另外一个开发人员添加到解决方案当中，下一次安装网络服务的时候就从VSS中刷新解决方案。在单解决方案系统中，没有必要在一个团队的中央服务器上发布网络服务。
对于作为多解决方案的一部分加以开发的网络服务，并不是所有的开发人员都需要将网络服务安装到本地。
在一个多解决方案系统中，网络服务的开发人员应当在中央开发服务器上发布服务，以便允许其它开发人员从客户项目中对其进行访问。
在开发中确定网络服务的版本
正在开发的网络服务会随着时间发生变化。应当致力于使Web服务器保持最新的版本。在许多方面，关于网络服务的版本问题与关于数据库的问题是相似的。当一个数据库模式被更新时，这些变化必须是符合计划的、协调的，这样，相关的客户应用软件能在模式发生变化的时候得到同步的更新。
应当以相同的方式去处理网络服务的更新问题。当改变一个网络服务的接口时，负责这个服务的团队必须发布这个变化，以便使其它相关的团队能够更新他们的客户端引用。
注意：实施的变化比起接口的变化而言比较不需要协调。然而，在两个场合中，负责网络服务的团队都应当向其它开发人员和开发团队发布更新过的细节信息。
始终使用动态的统一资源定位器（URL）
如果想调用一个网络服务，必须首先在项目中增加一个网络引用。这在和网络服务进行交互的过程中生成了一个代理类。代理的代码起初包含了这个网络服务的一个静态的统一资源定位器（URL），例如http://localhost或者http://SomeWebServer。
重要提示：对于运行在您的计算机上的当前解决方案中的网络服务而言，应当始终使用http://localhost，而不是http://MyComputerName，以保证引用在所有的计算机上都能保持合法性。
嵌入到代理中的静态统一资源定位器通常不是在生产或是测试环境中所需要的URL。典型的情况是，所需的URL随着您的应用软件从开发转移到测试再到生产而发生相应的改变。您有两个选项，可用于解决这个问题：
● 在创建一个代理类的实例时，可以有计划地设置网络服务的URL。
● 一个避免URL在代理中被固定编码的更加灵活的方案是，将网络服务引用中的URL Behavior设为dynamic。这是首选的方案。当您将属性设置为dynamic时，代码被添加到代理类中，以便从应用软件配置文件的<appSettings>部分获取网络服务的URL，该配置文件对于网络应用软件而言是Web.config，对于一个Windows应用软件而言SomeApp.exe.config。对动态URL方案也让您提供一个用户配置文件，此文件能够覆盖主应用软件配置文件。这允许独立开发人员（和测试团队的成员）临时将一个网络引用重定向到一个可替换的位置。
如何使用动态URL和用户配置文件
将网络服务引用的URL Behavior属性设为dynamic，以便在开发和产品环境中获得最大程度的配置灵活性。在应用软件配置文件中设置网络服务产品的URL，并且出于开发和测试目的提供一个用户配置文件。用户配置文件的缺失将致使应用软件配置文件投入使用。
Ø 要在一个用户配置文件中指定一个网络服务URL
1. 在主应用软件配置文件的appSettings元素中添加一个file="user.config"的属性。当运行期从appSettings部分获取信息时，这将自动地将运行期重定向到指定的用户配置文件。如果用户配置文件缺失，主应用软件配置文件中的相应设置将被使用，而不产生任何运行期错误。
<configuration>
<appSettings file="user.config">
<add key="ClientApplication.SomeServer.SomeService"
value="http://ProdWeb/myXmlWebService/Service1.asmx"/>
</appSettings>
</configuration>
在上述的例子中，ClientApplication.SomeServer.SomeService是网络服务代理类的合法名称。ClientApplication.SomeServer是域名空间，SomeService则是代理类名。
2. 创建一个User.config文件（位于应用软件配置文件的同一个文件夹中），然后添加一个包含了一个键值对的appSettings条目，该键值指定了网络服务的URL，就像下面的代码所解释的那样。请注意在这个例子中，URL引用了本地网路服务器。也请注意User.config文件中缺少<configuration>元素。
<appSettings>
<add key="ClientApplication.SomeServer.SomeService"
value="http://localhost/myXmlWebService/Service1.asmx"/>
</appSettings>
3. 不要在VSS中登记User.config文件。在这种方式中，每个开发人员（和测试团队）通过他们自己的User.config文件条目能够清楚地绑定到特定的URL上。主应用软件配置文件应当维护网路服务的产品地址，它将在User.config文件缺失的情况下投入使用。
提示：缺省情况下，用户配置文件被自动添加到VSS当中。为了阻止这个操作，在解决方案浏览器中右击该文件，然后点击Exclude From Project。为了后面能够在解决方案浏览器中看到该文件，在解决方案浏览器窗口的顶部点击Show All Files图标。
重要提示：对于采用用户配置文件的网络应用软件而言，对这个文件所作的任何变化不会导致网络应用软件的自动循环。这种情况仅在使用Web.config文件时可能发生。因此，对用户配置文件所作的变化不会立即被应用软件发现。必须手动停止并且重起网络应用软件。这就是为什么您应当使用Web.config文件作为产品设置而仅使用User.config文件作为开发和测试设置的另外一个原因。
更新一个网络服务引用
要更新一个现存的网络服务引用，在Visual Studio .NET的解决方案浏览器中，右击文件，然后点击Update。下次当您重新编译连接项目的时候，新的服务信息将以一个网络服务描述语言（WSDL）文档的形式被下载，并且一个新的本地网络服务代理也被创建出来。
引用数据库
以连接串的形式表现的数据库引用也能够使用User.config文件进行管理。这么做的优势是每一个开发人员能够在他自己私有的User.config文件中轻易地指定属于自己的连接串。一个开发人员所作的任何变化不会影响别的开发人员。
用户配置文件也能被用于控制环境特定的设置项，例如那些需要测试环境的设置项。测试环境也可以使用一个引用测试数据库的User.config文件。
这个过程与上述网络引用的例子相似，只是在那个例子中，网络服务代理包含了从配置文件获取网络服务URL的代码。对于数据库连接串，必须提供读该连接串的代码。
如何为数据库连接串使用用户配置文件
以下的过程解释了如何在一个用户配置文件中存储并且引用一个数据库连接串。
Ø 要使用一个用户配置文件去存储数据库连接串
1. 在主应用软件配置文件的appSettings元素中添加一个file="user.config"的属性，并且在主配置文件中包含一个缺省的连接串。这在不发生用户指定的覆盖操作的情况下使用。
<configuration>
<appSettings file="user.config">
<add key="DBConnStr"
value="server=PRODDB;Integrated Security=SSPI;database=Accounts"/>
</appSettings>
</configuration>
2. 要覆盖主应用软件配置文件，创建一个User.config文件（位于和应用软件配置文件相同的文件夹中），然后向文件中加入一个相似的appSettings条目。注意以下的连接串引用了一个本地数据库。
<appSettings>
<add key="DBConnStr"
value="server=(local);Integrated Security=SSPI;database=Accounts"/>
</appSettings>
3. 在项目中，使用以下的代码从用户配置文件（如果存在的话）中获取连接串，或者如果该文件不存在，则从应用软件配置文件中获取。这个代码使用了System.Configuration.ConfigurationSettings类的静态AppSettings属性。
using System.Configuration;
private string GetDBaseConnectionString()
{
return ConfigurationSettings.AppSettings["DBConnStr"];
}
数据库开发
在团队环境中有两种基本的方案可用于数据库开发：
● 中央数据库服务器
● 中央数据库服务器和开发工作站上的本地数据库。
中央数据库服务器
团队环境中的中央数据库服务器或服务器群反映出产品模式——或者如果系统还未投入生产，那么它们反映出最新的模式。下面对如何在团队环境中对数据库服务器的使用进行管理作出指导。
● 不要赋予开发人员对数据库进行管理访问的权力，并且不允许个别开发人员对数据库模式作出更改。需要对整个环境进行严密的控制，因为一个开发人员所作的更改能够轻易地影响别的成员。
● 给予开发人员特定的权限；例如，给予开发人员编写存储步骤、函数和（可能）视图的权利。
● 对模式变化和其它对象（例如带有源码控制的数据库脚本的存储步骤）进行管理。
● 使用数据库脚本使得数据库的创建和重建变得容易。
● 为独立的开发工作提供独立的数据库实例，因为配置设置项对每一个开发项目而言都可能是各不相同的。
本地服务器
与一个或多个中央开发数据库服务器相比，单独工作的主要问题是要维护一组统一的测试数据非常困难。某个开发人员所作的单元测试能够轻易地影响其他人员，因为测试数据可能频繁地发生变化。
因此，在每一台开发工作站上安装微软SQL Server™开发人员版本，以便为每个开发人员提供一个独立的测试环境，这种做法已经变得非常普遍。
使用数据库脚本对变化进行管理
应当使用源码控制的数据库脚本对数据库的所有变化进行管理，无论该数据库位于本地服务器上还是位于中央服务器上。应当提供脚本去管理您通过企业管理器手动作出的更改。您应当使用数据库脚本（包含了尽可能多的审核和错误记录功能）去：
● 允许一个数据库（包括存储步骤等等）从最开始进行安装。
● 允许一组新的测试数据被加载。
● 将更新应用于数据库模式和数据对象。
考虑Visual Studio .NET项目
数据库脚本应当是在VSS中受到源码控制和得到维护的。有两个选项用于处理脚本：
● 在Visual Studio .NET集成开发环境之外、VSS当中处理脚本并且手动创建一个适当的文件夹结构。例如，应当在$/Projects/SystemName下建立一个称为Database Objects的子项目文件夹，以维护数据库的特定代码和对象，然后使用独立的子文件夹例如Tables and Views、Diagrams andDocumentation以及Stored Procedures and Functions作为不同对象类型的容纳体。
● 使用Visual Studio .NET数据库项目。这些是简单的、基于项目的文件，允许存储和执行数据库脚本，并且存储其它与数据库相关的信息，例如数据库文档或者编译连接文件。Visual Studio .NET为Transact-SQL代码提供了一个集成编辑器，一个可视的Query Builder和T-SQL调试支持。这个方案的优点在于，它提供了和其他项目类型一样的、与VSS紧密的、自动的集成。
关于更多数据库项目的信息，请参考微软MSDN® 库中的文章——“在使用Visual Studio .NET进行开发的过程中管理数据库项目的数据”。也可以使用“Large Database Projects”在MSDN中进行搜索。
引用COM对象
当代码调用一个COM对象时，一个Interop组件被用于处理.NET系统和COM系统的类型转换问题。当COM对象从管理代码中被调用时，实际上是调用了Interop组件中的一个代理。这个代理先是执行必要的类型转换，然后唤醒COM对象去完成所要求的工作。
始终生成兼容的Interop组件
在一个团队开发环境中，如果您和其它的开发人员在两个不同的项目中引用了同一个COM动态连接库，结果是生成两个Interop组件——每一项目一个。
在多数情况下，两个生成的组件的类型是相同的，因此，将一个引用从一个项目到另一个项目传递给COM对象（通过Interop组件）的操作是安全的。
为了保证任意一个生成的Interop组件的类型能够是相同的，必须保证以下的这些条件得到了满足。如果做不到以下几点，当引用从一个项目传递到另外一个项目时，即使Interop组件从同一个COM动态连接库中生成，也将在运行期中引起一个类型匹配的意外错误。这些必须得到满足的条件是：
1. 所有的Interop组件必须从同一个版本的COM类型库中生成。
2. 所有Interop组件的特性必须相同。组件特性包括：
a. 不带扩展的文件名
b. 公共密钥，可能为空
c. 版本号
d. 生成背景（对于代码来说通常是中立的）
当从Visual Studio .NET项目系统中生成Interop组件时，通过从Add References对话框中选择COM类型库，通常可以使上述条件得到满足。唯一的例外是，Visual Studio .NET项目系统（或C#项目）为Interop组件指定一个明确的名称是可能的（项目属性对话框支持一个Wrapper Assembly Key File的属性）。在这个例子中，两个不同的开发人员可能会生成两个不兼容的Interop组件。
在一个团队开发环境中，为了保证在一个给定版本的COM类型库中只有一个Interop组件存在，应当采用以下两个方案中的一个：
1. 始终使用主Interop组件（PIAs）。
2. 如果您无法获得一个PIA，可以在一个Interop组件中手动生成（通过使用tlbimp.exe），然后：
a．随意地为这个组件指定一个明确的名称
b．从需要这个组件的项目中直接包含这个组件。
以下部分对上面两个方案作出描述。
尽可能使用主Interop组件
一个主Interop组件（PIA）是被COM对象的提供商正式签署发布的一个Interop组件，适用于所有场合。如果没有一个PIA组件，应当从COM对象的提供商处获得。如果拥有一个PIA组件，可以把它看作是一个外部系统组件并且直接从引用它的项目中包含它。这将使得组件被拷贝到项目文件夹当中。从项目文件夹中设置一个指向这个组件的文件引用。这个过程和先前描述的“从项目中包含外部系统组件”的一个过程是相同的。
注意：.NET框架提供的PIA组件位于\Program Files\Microsoft.NET\Primary Interop Assemblies文件夹当中。当您获得新的PIA组件时，不要将它们放置到这个文件夹当中。如果这样做了，需要更新团队开发环境中的所有开发工作站和编译连接服务器。相反，应当从需要引用它们的特定项目当中直接包含它们。
如果没有主Interop组件，请使用TLBIMP
如果没有PIA组件，请使用Tlbimp.exe工具去创建一个单独的Interop组件，并且为它指定一个明确的名字。类似于一个PIA（以及外部系统组件），请直接从需要引用它的项目中直接包含这个手动生成的Interop组件。这将使得组件从能够使用文件引用对其进行引用的地方被拷贝到本地项目文件夹中。
在本地注册COM类
如果向一个项目添加了一个Interop组件，它不会使得相关的COM动态连接库被拷贝（和注册）到本地，于是必须在每台开发工作站上注册这个COM动态连接库。不幸的是必须和一个没有得到管理的COM世界进行交互。
调用服务组件
服务组件是一个.NET管理的类，从System.EnterpriseServices域名空间的ServicedComponent类中派生出来。这样的类能够驻留在COM+应用软件中并使用COM+服务。
在一个团队开发环境中，在使用服务组件时，请采用下面的建议。
使用延时签名
服务组件必须拥有一个明确的名字。要指定一个明确的名字，需要一个能够使用Sn.exe工具生成的公共和私有密钥对。在许多公司中，私有密钥接近于商业机密，在日常开发中是不会向开发人员公布的。因此，应当使用延时或部分签名，它能够仅对公共密钥进行访问。
部分签名过程在组件移动执行文件（PE）中为明确的名称签署生成一个占位体。实际的签名被推迟到一个稍后的、位于系统测试和产品发布之间的一个阶段。编译连接协调器通常负责最后签署组件。
使用动态注册
应当增加相关的组件属性（例如，ApplicationName、ApplicationID和ApplicationActivation）以支持动态注册。这使得服务组件的实例一被创建出来，与您的服务组件相关的COM类型就能够自动地安装所有开发工作站的COM+目录中。
在COM+目录中控制CLSID的使用
缺省情况下，当重新编译连接一个组件时，它被指定一个新的版本号。这是因为对于新的项目，Visual Studio .NET将AssemblyVersion属性设为了“1.0”。因此，在每次组件被重新编译连接的时候都会为服务组件生成一个新的类标志符（CLSID）。
注意：这个行为在C#和Visual Basic .NET项目中表现得略有不同。对于C#项目，每次组件被重新编译连接的时候，组件版本号都会增加。对于Visual Basic .NET项目，只在项目被载入Visual Studio .NET之后的第一次重新编译连接时，组件的版本号才会增加。在Visual Studio .NET的同一个实例中进行的后续编译连接不会使组件的版本号增加。
这并不代表出了问题，因为组件版本号仅仅代表了没有一个明确的名称的组件的一些信息。对于有明确名字的组件，您应当使用需要手动维护的静态版本号。这个以及其他版本问题将在第五章——“创建过程”中的“控制组件版本号”中进行讨论。
为了控制COM+目录中的服务组件的CLSID，并且避免每次开发人员重新编译连接服务组件时出现多个版本号，可以使用以下这些方案中的一种：
1. 通过使用下面的Guid属性明确控制CLSID：
[Guid("2136360E-FEBC-475a-95B4-3DDDD586E52A")]
public interface IFoo
{
}
[TransactionAttribute(TransactionOption.Required),
Guid("57F01F20-9C0C-4e63-9588-720D5D537E66")]
public class Foo: ServicedComponent, IFoo
{
}
2. 为服务组件维护一个静态的组件版本号，不要使用Visual Studio .NET中缺省的“1.0”版本编号模式。有关更多组件版本的信息，请参阅第五章——“创建过程”中的“控制组件版本号”。
第五章 创建过程
本章将着重讨论下列问题:
● 管理方案和依存关系
● 使用合适的脚本和工具自动创建过程
● 规划分配创建的输出
创建过程是所有软件开发工程中必备的一个关键环节。不要试图省略这个步骤——对于一个团队开发环境尤其如此。开发者应该尽早在开发环节中配置一个构架服务来创建必要的创建脚本——当然这一步一定要在开始整合测试之前完成。
一个创建脚本的主要功能是提供一个能重复和可靠的自动生成系统构架的途径。在一般情况下,开发者安排创建脚本在夜间运行,这样能避免一些对服务器, Microsoft Visual SourceSafe(VSS)和网络构架的不可预知的干扰。
创建脚本通过使用VSS自动模型或是从命令行调用VSS来访问VSS。它能标识和析取最新的版本资源和工程文件,并且使用Microsoft Visual Studio.NET（通过在命令行中执行devenv.exe命令）来创建客户自己的解决方案。一般创建脚本都会为相应的系统创建一个调试版本和一个发行版本。
处理依存关系
在单一或是分开的解决系统中,工程基准负责依存关系和创建顺序的问题。为这些系统创建脚本相对较简单,因为在一个解决方案中可以运行一次Devenv.exe程序。
而多解决方案系统的创建脚本就要复杂许多，因为必须创建一个基于依存关系的正确的解决顺序。这样才能确保当一个集合更新时（版本也随之改变），所有参照它的客户端集合都能更新并创建一个最新版本的系统。
控制集合版本
一个集合的版本是通过AssemblyVerison属性参数来定义的（这个参数一般在AssemblyInfo.cs或是AssemblyInfo.vb文件中定义）。版本号一般显示为四个分开的数字,中间用点号隔开：
如 <major version>.<minor version>.<build number>.<revision>
开发者并不需要明示每个部分的更新情况，因为可以用字符*自动生成创建和修改的版本号。Visual Studio.NET生成一个用AssemblyVersion参数定义的AssemblyInfo源文件，如下所示：
[assembly: AssemblyVerison(“1.0.*)]
用以上模型创建的数字结果被设定为日期的数字，它从一个随机指定的开始日期和基于从午夜开始的时间修改日期开始。
开发者可以使用自动增益的版本号字或是选择手动控制的版本号来作为创建过程的一部分。上述两种途径都有其优势和不足之处。
注意：对于一个AssemblyVersion参数设定为”1.0.*”的Microsoft Visual Basic .NET的工程，集合的版本只在工程在Visual Studio .NET整合开发系统(IDE)中首次重建时才会更新，而在接下来的在同一个开发环境中重建的过程中，版本号都保持不变。这种设计并不会开来什么问题，因为集合版本信息只是提供给那些没有强名称的集合的。对于强名集合，开发者应该避免在AssemblyVersion参数中使用字符,这一点将在后续内容中解释。
对于一个AssemblyVersion参数设定为”1.0.*”的C#工程，集合版本在每次重构时都要更新。
使用自动增加的版本号字
通过在AssemblyVersion参数中使用默认的“1.0.”格式，就创建了一个版本号自动增加的系统。
优点
使用自动增加版本号有以下优点：
● 创建和重构的数字被Visual Studio.NET自动处理而不需要使用创建脚本或是创建协调程序。
● 开发者能保证在重建有相同版本号的集合时不会碰到麻烦。
缺点
使用自动增加的版本号有以下缺点：
● 内部的集合创建版本号和系统创建版本号不一致,这就意味着不能很方便的将一个特定的集合和生成它的创建系统相关联。这在开发者需要在一个产品环境中支持系统时显得尤为突出。
● 创建和重构的版本号并不是逐个增加而是取决于系统重构的时间。
● 一旦一个集合重构，就会有一个新的版本号产生,而不论集合本身是否发生了变化。对于强名集合，这就意味着每一个客户都必须同步更新他们的版本号来和系统保持一致。然而,如果是整个创建过程重建，那这就不成为一个问题。
使用静态的版本号
通过这种方法,开发者可以使用一个个静态的版本号，如“1.0.1001.1”，而只在新版本发布时更新主要或是次要的版本。
优点
使用静态版本号有以下优点：
● 开发者可以对特定的版本号做到完全控制。
● 集合创建的版本号能和系统创建的版本号保持同步
缺点
使用静态版本号有以下缺点：
● 版本号必须用创建协调程序或是创建脚本手动更新。
● 如果版本并不是随着每一次重建而增加的,那么开发者就要面对多个创建的集合有相同强名的问题。这对安装在全球集合系统（GAC）中的集合来说构成一个大问题。
要点：如果开发者不需要改变一个强名集合的版本号，而试图使用Microsoft Windows操作系统安装工具将它安装在GAC中,而GAC中原先存在一个相同的版本号，那么最新的动态链接库（DLL）就不会被安装。
如果开发者使用Gacutil.exe而不是Windows Installer来安装这个集合，那么最新的DLL在上述情况下仍然会被安装。
考虑集中集合的版本号
对于更新多个集合的版本信息，创建脚本或是协调程序必须检查并更新多个AssemblyInfo文件。要将这些文件集中成一个文件来检查和更新，可以考虑采用以下几种方法：
1. 将AssemblyVersion参数置于一个单独的源文件中，例如AssemblyVersionInfo.cs或是AssemblyVersionInfo.vb。
2. 在VSS中共享访问所有需要使用同一个版本号的工程。
这种方法是假定开发者需要将同一个版本号分配给由同一个特定系统创建的所有集合。而这对于特定的系统可能合适，也可能不合适。
构架服务器文件夹结构
开发者需要在服务器上创建相同的基本文件夹结构来作为开发工作台。因此，关于基本文件夹结构的讨论在第三章：使用一个一致的文件夹结构来为工程提供解决方案中，构造解决方案和工程仍是推荐的服务器结构。
考虑维护原有的结构
开发者有可能希望创建一个基于创建版本号的新文件夹结构来维护原有系统的输出。这样做的好处是它能使测试小组方便的安装和测试一个特定的版本系统而不被正在进行的其它开发环节所影响。
构架服务器文件夹结构的示意图如下（图5.1）
图5.1 构架服务器文件夹结构示意图
上图主要关注以下信息：
● 创建由创建版本号规划，一个生成创建版本号的简单方法将在后续章节中描述。
● 最新的文件夹总是包含最后创建的系统的输出——这符合最新创建的文件夹的二元包含。
● 每个工程的输出文件件的内容被创建脚本拷贝到最新发布的文件夹的一个子文件夹下,文件名取决于工程的名称。
在一个多重解决方案系统中，开发者可以参考其它解决方案的集合创建，这也在最新发布的文件夹的一个子文件夹下。这个文件夹在每次创建后都重构，这就保证开发者参考的是最新更新的集合,而且是最新的版本号。
如果在一个多重解决方案的系统中需要一个孤立的开发系统（没有联网），开发者可以拷贝创建的输出到他们本地的工作台上，并使用虚拟驱动来参考本地集合。
不改变创建的输出路径
开发者可能试图改变工程的输出路径来创建一个单一的文件件，继而为这个文件夹创建一个文件基准。因为以下原因,不推荐使用这种方法：
当引用集合超过64KB大小时，这将导致创建过程因文件锁定错误而失败。这个问题将在将来的Visual Studio.NET版本中被修正。
当引用一个被设置为工程输出的文件夹时也会碰到问题。在这种情况下，Visual Studio .NET不能拷贝本地集合因为拷贝操作的源文件和目标文件同名。如果开发者随后将这个参考文件夹移出工程,Visual Studio.NET就会取消本地的拷贝操作。这是因为本地文件夹和集合的起始文件夹相同,而起始集合被删除了。
创建脚本
图5.2显示了创建脚本所要采取的每一个步骤：
图5.2 创建脚本所要采取的每一个步骤
下列章节描述了创建过程的主要步骤。
生成创建版本号
连续的创建过程要通过唯一的创建版本号来区分。创建版本号被用来命名输出文件夹。而输出文件夹中包含每一个特定的创建过程的输出结果并且可以在VSS中标识源文件。
创建版本号一般是一组递增的数字,相对于系统唯一。有很多方法可以生成版本号。一个简单的途径就是在最新的文件夹中保留一个文本文件，而这个文本文件的名称代表了最新的创建版本,例如2021.txt。创建脚本可以访问这个文件来生成后续版本。
标识源文件
创建起一个特定的构架和一套工程以及生成这些构架的源文件之间的联系是十分重要的。达成上述目标的最简单的阿方法就是用现有的创建版本来标识最新的源文件。
这使得开发者可以在未来需要的情况下，在任何时候重新创建一个构架。这在需要解决一个破碎的构架时也能发挥作用,这将在后续章节中描述。
下列的脚本片断显示了怎样利用VSS的命令行模式一个给定的VSS工程文件夹中标识一套文件。而要在系统中标识所有的源文件,那么顶级的VSS文件夹应该被设为$/Project/SystemName。
析取最新的源文件
创建脚本执行一个获得操作来从VSS中析取最新的源文件集合。它使用分配的标识来取出正确的源文件。源文件被取出后放到构架服务器的一个普通文件夹结构下，如前面的图5.1所示：:
下面的脚本片段显示如何用VSS的命令行执行获取操作：
创建一个最新的文件夹
创建过程经常将生成的集合拷贝的最新的文件夹中，这样才能保证任何一个文件参考的都是多重解决方案系统中最新的集合版本。
用Devenv.exe创建解决方案
通过执行Devenv.exe程序，脚本能创建独立的解决方案,并尽可能少的提供解决文件名，重建开关(这能确保所有的输出和临时输出文件在开始时被删除)和需要的解决方案配置。创建脚本要运行Devenv.exe两次，一次生成一个发布的构架,另一次生成一个调试的构架。下列脚本片断显示如何运行Devenv.exe：
创建脚本分析输出的由Devenv.exe生成的创建日志，以此来观测最新的解决方案是否成功。
对于包括跨解决方案的文件参考的多重解决方案系统，一个特定的解决方案的发布构架必须在调试构架前生成,这才能保证所有的文件参考能被分解。这是假定开发者将文件引用设定为发布版本的集合，这一点将在第四章“管理依存关系”中的有关“和文件引用一起发布的构架”中讨论。
将输出拷贝到最新的文件夹中
单一的解决方案或是分开的单一解决方案系统不需要一个最新的文件夹,因为开发者使用的是工程参考而不是文件参考来决定内部系统集合。对于这种类型的系统，创建脚本能简单的在相关创建文件夹下获取输出。
然而对于多重解决系统，在每一个解决方案都创建之后,所有组成工程的输出集合必须被拷贝到最新发布的或是最新调试的文件夹下，以保证随后的工程创建在其它解决方案参考的最新集合版本之内。
注意：创建脚本能使用许多通过命令行验证的解决方案,来推断是否正在处理一个多重系统。如果解决方案的数量大于1,那么必须拷贝集合输出到最新的文件夹。否则,这个步骤可以省略。
在最新的文件夹下规划集合输出
集合被拷贝到最新发布或是最新调试的文件夹的子目录下，而这些子目录的名称取决于工程的名称。之所以要将所有的输出集合直接转移的最新发布的文件夹下，是因为这样做能更清晰的规划输出结果，而且使得同名的外层系统集合的两个版本（如第三方的集合）能被包含在不同的工程中。
值得注意的是外层系统集合并不是创建过程的一部分，并且应该被包含在工程中以作为参考。这使得两个工程参考不同版本的第三方集合（同名）成为可能（尽管可能性不大）。如果开发者将创建输出分开到不同的字文件夹下，那就能保证这些DLL文件没有覆盖原来创建脚本拷贝过来的文件。
拷贝最新的文件夹来创建一个版本文件夹
如果成功的创建一个多重系统，最新的文件夹的内容就会被拷贝到一个以当前版本号命名的文件夹中。这使得连续创建过程成为可能。
将最新文件夹改名为LatestBroken
如果创建失败，创建脚本就会将最新的文件夹改名为LatestBroken，并且将LatestBackup文件夹恢复成最新的文件夹。这使得所有参考构架服务器上的最新文件夹的开发者能继续他们的本地开发。
解决一个失败的创建过程
创建的协调程序必须尽可能快的处理一个失败的创建过程。一般一个或多个源文件会有错误，要么需要在VSS中更新，要么最新底改变需要被一起备份。
如果开发者在VSS中更新源文件，那么必须使用VSS Explorer用当前底创建版本手动标识这些文件。这能保证这些更新的文件和现有的创建过程相关联。
当开发者更新了相关的文件并且希望返回当前底创建过程，创建脚本应该提供当前底创建版本号作为命令行的一个参数。如果缺少创建版本号，那就意味着创建一个新的系统。如果一个创建版本号被给出，那么使用这个号(这和源代码标识相匹配)就可以从VSS中析出相关的源文件。
重新创建多重解决系统
当一个创建过程在运行时，开发者可能会碰到本地的编译问题,尤其是在一个多重系统上工作，并在构架服务器上使用文件参考时。这是因为创建过程在开始时清除了最新的文件夹。
要避免这个问题,开发者应该切换到一个独立的开发模式，这个模式在第四章“考虑一个独立的开发环境”中有详细描述。这在工作在多重系统上时显得尤为重要。通过这种方法,开发者通过可能在白天运行的创建过程获得保护。
Email发送创建结果
创建的结果应该通过Email发送到开发团队，为成功和不成功的创建过程参考。这个email信息应该包含创建日志的附件，使开发者能诊断创建错误或是识别代码产生的警告信息。
要避免在创建脚本中的email硬代码伪址，开发者应该设定基于工程或是解析名的分布列表。
创建过程打包
为了使最新创建的系统更方便的被安装到测试（或是开发）环境,开发脚本能在Microsoft Installer（MSI）文件中将输出打包。
对于单一解决方案（或是分离式的单一解决方案）的系统，开发者可以在解决方案中包含一个Visual Studio.NET Setup和Deployment工程。这能被用来自动生成一个MSI文件，作为解决构架的一部分。
注意：将Setup和Deployment排除出Visual Studio.NET的Configuration Manager（在Build菜单中），可以防止在创建解决方案时每次都重构一次。如果开发者用这种方法将一个工程从解决方案中排除，就不会影响到源文件影响的解决文件。相关的变化只保存在用户选择的文件中,而这是开发者定义的，不受源控制。
无论何时向解决方案中添加新的工程,一定要更新并设置配置工程，来保证新工程的输出被包含在MSI文件中，并且任何一个工程特殊的安装步骤都能被执行。这项工作一般是创建协调程序的责任，开发者有新的工程添加就要通知给协调程序。所有的开发人员都必须熟悉这个过程,确认这是开发过程指南的一部分。
多于多重解决系统，情况仍然要复杂许多。因为单一的Setup和Deployment工程只能被用来打包单一的解决方案生成的工程。在这种情况下,创建脚本能通过使用第三方软件或是Windows Installer软件开发包（SDK）生成MSI。
创建创建脚本账号
开发者必须创建一个Windows账号，这样才能在构架服务器上为了一些特殊的目的运行创建脚本。这个账号必须能够访问共享文件夹或是VSS服务器上的文件夹，后者管理VSS的数据库。
开发者同样必须在每一个VSS数据库中创建一个创建脚本用户，因为创建脚本需要访问这些数据库的权限。这项功能在脚本访问VSS数据库时启用。
更多信息
关于VSS自动创建过程的更多信息,参见“Visual SourceSafe 6.0 Automation”，网址是：
http://msdn。microsoft。com/library/default。asp?URL=/library/techart/vssauto。htm。
第六章 使用Visual SourceSafe工作
本章将帮助开发者使用Microsoft Visual Studio.NET提供的整合资源控制功能来完成以下的开发任务：
● 创建解决方案和工程
● 在现有的解决方案和工程的基础上工作
● 为现有的解决方案添加一个新的工程
● 检查Microsoft Visual SourceSafe(VSS)中的源文件
● 对工程、文件和文件夹进行重命名和删除
本章将展现操作中一系列的细微步骤，这些步骤将引导开发者完成一些类似日常工作基础上的任务。
注意：本章所描述的内容适用于Visual SourceSafe6.0c的版本。
Visual Studio.NET提供完整的VSS支持。因为Visual Studio.NET清楚组成不同类型的。NET工程的各种不同的文件类型，所以用Visual Studio.NET对VSS中或VSS以外的工程文件进行日常检查是十分重要的。它能自动的将适当的文件置于源控制之下，而不去碰用户定义的文件。Visual Studio.NET的源控制功能也为它的解决方案和工程文件添加了一些自己特殊的信息。如果开发者直接使用VSS Explorer，这个功能就被略过。
图6.1从一个高的视角显示了开发过程和开发者在使用VSS时经常会运行的4种普通的任务。
图6.1 使用VSS时经常运行的4种普通任务
正如上图所示，有四种基本的任务是作为开发工具经常要被运行的：
● 创建一个新的解决方案和工程然后将它们添加到VSS中去。
● 第一次在现有的解决方案的基础上运行。
● 在原来已经使用过的解决方案的基础上运行。
● 将一个新的工程添加到一个现有的解决方案中去。
本章解释了为什么开发者需要运行上面提到的每一种任务和一些开发者偶尔会使用的任务，例如在源控制的VSS工程中对工程、文件、文件夹重命名和在一个多重调出模式中使用VSS。
创建一个新的解决方案和工程
在这种情况下，开发者希望创建一个新的解决方案，而它里面开始就包含了一个工程并且以后还可以向VSS中添加工程和解决方案。这种创建Web和非Web类型工程的过程以及采用推荐文件夹结构的想过内容在第三章”构架解决方案和工程”中有详细描述。下面的过程假定开发者已经按照第三章所述结构创建了解决方案和工程。
注意：每一个工程都包含一个全球唯一的标识符(GUID)，这样才能在一个解决方案中识别出一个工程。因此，开发者不能拷贝和重命名一个现有的工程来创建一个新的，因为这样做两个工程将会有同一个GUID，从而不能被Visual Studio.NET区分开来。将这两个工程包含在同一个解决方案中将会带来问题。
怎样向VSS中添加一个新的解决方案
当开发者使用Visual Studio.NET创建了一个新的解决方案和工程文件后，并经过一些初始的开发步骤，开发者应该将这个解决方案和工程添加到VSS中。
将一个新的解决方案添加到源控制中
1. 在文件菜单，先指向Source Control对话框，点击Add Solution to Source Control按钮。如果开发者向VSS中添加一个ASP .NET Web的应用程序，就会显示以下的源控制信息对话框。
2. 选择Don’t show this dialog box again的方框，再点击Continue按钮关闭这个对话框。
3. 然后系统可能会显示VSS登录的对话框。这只在VSS管理员没有将VSS配置成自动使用网络用户登录时才会出现。输入相应的VSS用户名，然后点击Browse按钮来在VSS服务器上定位VSS数据库。选择Srcafe.ini文件来在VSS服务器共享文件中确认开发数据库。
注意：如果已经配置成自动登录网络用户模式，就不会看见VSS登录对话框。在这种情况下，如果开发者希望更换VSS数据库，就要运行VSS Explorer，然后在文件菜单上点击Open SourceSafe Database。接着浏览合适的Srcsafe.inf文件。
4. 然后请输入数据库的名称－它代表目前正在运行的系统名称。点击Open，再点击OK来连接到数据库。
5. 在Add to SourceSafe Project对话框中，扩充Projects，然后选择系统的名称
6. 点击Create按钮。这就为开发者的解决方案文件创建了一个特殊的VSS工程文件夹。这个文件夹和Visual Studio.NET解决方案有相同的名称。
7. 点击OK。
要点：如果用户向VSS中添加一个ASP .NET Web应用程序，需要将每个Visual Studio .NET工程添加到VSS中。仅对于网络应用程序（下列两个步骤不适用于非网络应用程序）有：
a 扩展Projects，扩展系统名称，然后点击解决方案名称，再点击OK。
b 需要创建一个新的VSS文件夹来装载这个工程。点击Yes来创建一个新的文件夹。在解决方案中所有的网络应用程序都要重复这个步骤。
这样所有的解决方案、工程和源文件就都在VSS中源控制之下了。注意在所有的文件被添加到VSS之后，Solution Explorer窗口中有一个关闭的符号。这意味着现在这些文件在VSS中都被锁定了。本地的工作文件都配设置成只读属性以防止调用，直到使用者从VSS中选择了这些文件。
调出并编辑
如果开发者接着想编辑本地的文件，Visual Studio.NET有自动的调出编辑特性供使用者调用。如果使用者想继续编辑文件，点击Check Out For Edit对话框中的Check Out按钮。这个文件就会被自动调出。使用者也可以在Solution Explorer中右击文件，然后点击Check In将这个文件添加到VSS中。
第一次在现有的解决方案的基础上运行
在这种情况下，如果另一个开发团队人员创建了一个解决方案并添加到VSS中。而现在希望第一次调用这个解决方案并对它包含的某个工程进行操作，需要如下步骤：
从VSS中获取一个现有的解决方案
1. 运行Visual Studio.NET。
2. 打开File菜单，点击Source Control，然后点击Open From Source Control。然后系统就会显示VSS登录对话框。
3. 输入VSS用户名，然后点击Browse按钮在VSS服务器中定位VSS数据库。选择Srcsafe.ini文件来在VSS服务器共享文件中确认开发数据库。如果以前曾连接到这个数据库上并选择Open this database the next time I run Visual SourceSafe选项，那么这个数据库就会被预选中。
4. 点击OK来连接服务器。然后就会显示Create local project from SourceSafe对话框。
5. 扩展工程，扩展系统名称文件夹，然后点击希望获取的工程。在Create a new project in the folder编辑框中，输入\Projects\SystemName\SolutionName，其中SolutionName是解决方案的名称。这能保证使用者有一个正确的本地文件系统结构。
6 点击OK。如果本地解决方案文件夹不存在，使用者应该创建一个。点击Yes to All来创建解决方案文件夹。对于非网络应用程序，这样操作也能创建工程子文件。
7 对于ASP .NET网络应用程序，首先要在Set Project Location对话框中输入一个工作域提供给网络应用程序。也可以输入一个URL作为指向网络应用程序的虚拟根目录。Visual Studio.NET的默认路径是http://localhost/<projectname>。如果点击OK接受默认路径，那么新的虚拟根目录就创建在默认节点下（一般是\Inetpub\wwwroot）。在团队开发环境中不推荐这个路径，虽然开发者有可能希望能创建本地的应用程序。要想在解决方案文件夹下的工程文件夹中创建一个虚拟根目录，在Set Project Location对话框中要进行以下几个步骤：
a 使用Microsoft Windows Explorer来创建一个工程子文件夹，它位于\Projects\SystemName\SolutionName下的解决方案文件夹中。用工程名称来给这个字文件夹命名。
b 使用Windows Explorer或是Microsoft Internet Information Services（IIS）将这个文件夹设置为IIS的虚拟根目录。
c 返回Visual Studio.NET并输入http://localhost/projectname/作为工作路径。
要点：使用者必须改写现有的URL或是对话框，假定地址仍映射到位于\inetpub\wwwroot下的一个文件夹中。
d 点击OK关闭Set Project Location对话框。这样就将工程和网络应用程序文件放置到虚拟根目录下，而它映射到位于解决方案文件夹的一个一级子目录下。
8. 现在解决方案、工程和源文件都被下载到本地硬盘上了。然而，需要注意的是它们仍被锁定在VSS中。Solution Explorer中每个文件后面的锁定符号证明了这一点。
9. 现在开发者可以在Solution Explorer中选择一个或是多个文件，右击然后点击Check Out，或是简单的开始编辑源文件。因为当一个文件需要被调出时，Visual Studio的编辑特性会自动做到这一点。
10. 当开发者完成了本地的开发，就可以单独加载某个文件或是使用整合在开发环境中的Pending Checking窗口。可能需要点击View菜单下的Pending Checking来显示这个窗口。
注意：如果开发者退出解决方案而没有加载文件，这并不会得到系统提示。这些文件仍用使用者的用户名被调用着。
接着在现有的解决方案和工程的基础上工作
在这种情况下，开发者希望在以前至少被使用过一次的现有的源控制解决方案的基础上工作。因此，本地的文件系统包含一个解决方案和工程文件夹，里面是只读的解决方案和工程文件。
从VSS中获取一个现有的解决方案
1. 启动Visual Studio .NET。
2. 如果需要的解决方案已经显示在开始页面上，那么点击这个解决方案。否则，用浏览解决方案文件（.sln）的方法打开本地文件系统上的这个解决方案。
为了确保能获得最新更新的工程文件，可以在Solution Explorer中选择解决方案，然后点击Get Latest Version（Recurisve）按钮。
要点：当在以前曾经从VSS中获取到的解决方案上工作时，应该打开本地解决方案文件。这种情况下不要使用Open From Source Control菜单选项。如果这么做，Visual Studio.NET会探测到本地解决方案和工程文件的存在，并提示覆盖这些文件。同时，如果有一个和多个这样的文件被调出，系统会提示用VSS的本版取代这些本地文件，或者是不打开这些版本的本地文件。这样打开本地解决方案文件就不容易发生错误。
将一个新的工程添加到一个现有的解决方案中去
在这种情况下，开发者希望将一个新的工程添加到一个现有的解决方案中。下列的步骤假定开发者已经用前面描述的方法从VSS中获取了解决方案。
添加一个新的工程到VSS中
1. 在文件菜单中，指向Add Project，然后点击New Project。
2. 选择合适的工程类型和模板，然后为工程命名。
3. 对于ASP .NET网络工程，开发者必须在解决方案文件夹下手动创建一个子文件夹，并将它作为IIS的虚拟根目录。对于非网络应用程序，新的工程文件夹默认位于解决方案文件夹下的一级子目录下。
4. 点击OK。Visual Studio .NET自动提示开发者调出解决方案文件（如果文件还没有被调出的话），因为需要向这个文件中添加新工程的一些细节。
5. 点击Check Out。新的工程就被添加到解决方案中并显示在Solution Explorer里。注意新工程的每一个文件后面都有一个勾的符号。这表明这些文件都没有被锁定而且可以被修改。
6. 当开发者完成了新工程文件的初始开发工作，这些文件必须被加载到VSS中。要添加整个解决方案（包括新的工程）到VSS中，右击Solution Explorer中的解决方案，然后点击Check In。
7. Check In对话框显示所有的文件目前都被调出。这包括新的工程文件和源文件。要加载这些文件，点击Check In。
加载源文件到VSS中
当解决方案和工程都被加载到VSS中之后，开发者只需要加载那些更新过的文件。首先右击Solution Explorer中的单一文件，然后点击Check In。或者，可以通过Pending Checking页面来查看所有需要加载的文件列表，它们被显示在IDE的底部。通过这个页面一次可以很方便的加载多个文件。
只加载那些待建的文件
一般来说，只有那些被认为是经过完整测试，和开发团队其它成员更新的工程一起创建时不会引起整合问题的工程和文件才会被加载到VSS中。
重点：这就意味着一些文件有时经过几天都不会被加载到VSS中。因此，要确保整个开发环境每天都有充足的备份工作。
注意：如果使用的是一个改变的管理系统，而它本身支持提升层的概念，那么开发者最好定期加载文件，而不管它们目前的状态是否是被完成。支持提升层的改变管理系统一般都提供一个初始的开发环境。创建过程从不会从这个层中析取源文件。相反，它将源文件和一些更高层次（如整合层）的文件一起操作。只有当文件可以被和整个系统创建整合时，开发者或是协调程序才能将文件提升到这个层。
文件与文件夹的重命名和删除
有时开发者需要在源控制的VSS工程中删除或/和重新命名一些文件或是文件夹。用Visual Studio.NET IDE执行删除或是重命名操作并不是自动完成的。因此，开发者必须和VSS Explorer一起使用Visual Studio .NET.
对文件进行重命名
下列步骤显示了怎样在一个Visual Studio.NET工程中重新命名一个文件。
重命名一个Visual Studio.NET工程中包含的文件
1. 使用VSS Explorer来保证希望被重新命名的文件已经被调出。
2. 使用VSS Explorer来重新命名这个文件。
3. 使用Visual Studio.NET来打开包含这个工程的解决方案。这个已经在VSS中被重命名的文件在Solution Explorer中被显示调出。如果开发者已经在Visual Studio.NET中加载了这个工程，那么在Solution Explorer中选择工程文件右击，然后点击Get Latest Version（Recursive）。
4. 在Solution Explorer中选择文件右击，然后点击Rename。将文件名修改得和VSS中得一致。
5. 接下来将会被提示调出这个工程文件，因为它包含一个文件目录。在Check Out For Edit对话框中，点击Check Out。
6 在Source Control信息框中，点击Continue with Change。
7. 目前显示这个文件被锁定在Solution Explorer中。将它加载到VSS中。
重命名一个工程
当开发者要重命名一个工程时，需要重命名以下项目来保持名称得一致性约定，这一点在第三章的“仔细考虑名称约定”的相关章节中详细描述过了。这些项目是：
● Visual Studio.NET工程文件
● 包含工程文件的本地文件系统文件夹
● VSS工程文件夹
● 输出集合文件夹
● 工程使用的根名字空间
重命名一个工程
1. 首先确保以下这些文件没有被调出：工程文件，包含工程文件的解决方案文件或是其它任何包含在工程中的文件。
2. 调出解决方案文件。在Visual Studio.NET Solution Explorer中选择解决方案，右击，然后点击Check Out。确保在Check Out对话框中只有解决方案文件（没有工程文件）被选中，然后点击Check Out。
3. 现在必须解除工程和VSS数据库的绑定。在Visual Studio.NET中，指向文件菜单中的Source Control，然后点击Change Source Control。
4. 选择希望更名的工程（这也就自动选择了解决方案）然后点击Unbind按钮。在接下来的Source Control信息框中，点击Unbind。
5. 点击OK来关闭Change Source Control对话框。工程文件（也可能是解决方案文件）目前已经不绑定在VSS数据库上。
6. 在Solution Explorer中，右击希望更名的工程，然后点击Rename。输入新的工程名称。
7. 在文件菜单，点击Save All来保证本地的解决方案文件被更新。
8. 现在必须暂时将工程从解决方案中移出，这样才能重命名本地的工程文件夹。在Solution Explorer中右击重命名工程，然后选择Remove。在接下来的Microsoft Development Environment信息框中，点击OK。
9. 使用Windows Explorer来重命名本地的文件系统文件夹于更名后的工程保持一致。
10. 如果开发者重新命名一个网络应用程序，使用Windows Explorer或是IIS来创建重命名文件夹，并将其作为IIS的虚拟根目录。同时，使用Notepad来编辑.工程文件夹中的webinfo文件并设置URLPath参数指向工程新的虚拟根目录。
11. 返回到Visual Studio.NET，在Solution Explorer中右击解决方案文件名称，点击Add，然后点击Existing Project。浏览重命名的本地工程文件夹，选择重命名工程文件，然后点击Open。
12. 使用VSS Explorer来重命名VSS工程文件夹，使之和更名的工程保持一致。
13. 现在可以重新将工程和VSS数据库绑定。返回到Visual Studio.NET，指向文件菜单中的Source Control，然后点击Change Source Control。
14. 如果解决方案现在被解除绑定，在Change Source Control对话框中选择它，然后点击Bind。现在可能需要登录到VSS中。在VSS中找到解决方案文件夹，选中它，然后点击OK。
15. 在Change Source Control对话框中选择重命名工程，然后点击Bind。如果需要可以登录到VSS中。
16. 在VSS中找到解决方案文件夹，选中它，然后点击OK。
17. 点击OK关闭Change Source Control对话框。在接下来的Source Control信息框中，点击OK。
18. 使用Pending Checkins窗口将解决方案和重命名的工程文件加载到VSS中。
19. 现在可能需要调出相关的源文件，然后更新它们的根名字空间以和更名的工程保持一致。
20. 同时调出工程文件并更新工程属性，包括控制输出动态链接库或可执行文件的Assembly Name。同时，对于C＃工程，更新Microsoft Visual Basic.NET工程默认的名字空间，根名字空间。因为这些控制添加新类型的默认的名字空间。
整理旧工程的文件
旧工程的文件、相关的源控制元数据文件，和对于网络应用程序来说的网络服务动态文件仍保存在更名后的VSS工程文件夹中，这些工程文件夹保存在本地的文件系统中。
现在需要将这些旧文件删除：
1. 使用VSS Explorer从更名的工程文件夹中删除旧的工程文件（.csproj.proj），旧的Visual Studio Source Control Project Metadata文件（.csproj.vspcc）和对于网络应用程序来说的，旧的网络服务动态文件（.vsdisco）。有可能需要在VSS Explorer中刷新来看到新的工程文件。
2. 使用Windows Explorer从本地更名后的文件系统工程文件夹中删除旧的Visual Studio Source Control Project元数据文件（.csproj.vspcc）和对于网络应用程序来说的，旧的网络服务动态文件（.vsdicso）。需要注意的是这些文件在本地文件系统中的属性是只读。
3. 对于网络应用程序，使用IIS来移除旧的目前已被重命名的虚拟根目录。
从VSS中删除一个文件
下列的操作假定开发者已经从VSS中打开了一个解决方案，而且其中至少包含一个工程，而这个将被删除的文件也在这个工程中。
删除一个文件
1. 确保想要删除的文件没有被调出。
2. 在Solution Explorer中，右击想要删除的文件，然后点击Check Out
3. 在Check Out确认对话框中，点击Check Out。如果这个文件因为其它人的操作而没有准备被调出，必须等待，直到对这个文件操作的只有当前使用者。
4. 在Solution Explorer中，右击文件，然后点击Delete。
5. 在接下来的Microsoft Development Environment信息框确认是否真的要永久删除这个文件，点击OK。
6. 系统会提示调出工程文件，因为它包含一个文件目录。在Check Out For Edit对话框中，点击Check Out。
7. 加载工程文件到VSS中。
8. 使用VSS Explorer从VSS数据库中删除文件（就是目前被调出的那个）。在接下来的Microsoft Visual SourceSafe信息框中，点击Yes确认删除文件。
从VSS中删除一个工程
下列步骤显示怎样从VSS中删除一个工程。
从VSS中删除一个工程
1. 在Solution Explorer中，右击希望删除的工程，然后点击Remove。
2. 在Microsoft Development Environment确认信息框中，点击OK。
3. 系统会提示调出解决方案文件，因为它包含一个工程列表。在Check Out for Edit对话框中，点击Check Out。
4. 将解决方案加载到VSS中。
5. 使用VSS Explorer从VSS数据库中删除这个工程。
6. 从本地的硬盘上删除工程的文件夹。对于网络应用程序来说，使用IIS移除相应的虚拟根目录。
从VSS中删除一个解决方案
下列步骤显示怎样从VSS中删除一个解决方案
从VSS中删除一个解决方案（其中包含工程）
1. 在VSS Explorer中，确认下列文件没有被调出：解决方案文件，任何的子工程或是工程文件。
2. 使用VSS Explorer从VSS中删除这个解决方案。
3. 从本地硬盘上删除这个解决方案。
注意：当试图删除一个解决方案时，需要和开发团队的其它人员联系，如果他们正将这个解决方案加载到Visual Studio.NET中，那就要求他们退出加载。如果在删除时任何一个团队成员加载了（没有被调出），在他们试图调出包含在解决方案中的文件时，系统会对这些人提示VSS错误。
多重调出
一般来说，一个用户一次只能从VSS中调出一个文件。然而，开发者可以使用VSS Administration工具配置VSS，使它允许同时调出同名文件。
这在一个团队开发环境中是十分重要的，因为它能使开发者从普通的文件访问（如工程文件）中解脱出来。然而，如果使用了这个特性，需要仔细协调团队中的个体成员，并且在向VSS中加载文件时要确保正确。
使用多重调出模式下的文件
1. 使用Solution Explorer来调出所需要的文件。当文件已经被另一个用户调出时，Visual Studio.NET会警告使用者。在接下来的Microsoft Visual SourceSafe信息框中，点击Yes。
2. 对文件的拷贝做了改动后，需要不停的编译测试这个工程。
3. 在加载文件之前，需要拼接其它开发者对这个文件做的改动，然后和当前开发者做的改动一起测试。为此，在Solution Explorer中右击这个文件，然后点击Get Latest Version。在接下来的Microsoft Visual SourceSafe信息框中，点击Merge。VSS会自动将系统版本和本地版本的文件拼接。现在就可以编译并测试拼接后的文件。
4. 当测试结束后，使用Visual Studio.NET将文件加载到VSS中。如果文件被拼接过，VSS会提示开发者是否所有的冲突都被解决了。点击Yes回答这个提示，这样这个文件就被重新加载到VSS中了。
调出解决方案文件
解决方案文件很难被同时调出，因为它们包含的工程量使得拼接过程十分困难，会产生错误。在其它开发者已经调出某个解决方案文件的情况下，开发者应该尽量避免调出此文件。
相反，针对一次短时间的调出解决方案文件（如添加新属性）可以解决对这个文件的争用。当发生争用时要和其它开发者协调，并在此文件没有被他人使用时再调出它。
更多信息
对于有关多重调出的更多信息，参见“Check Out Multiple Files”，它位于
第七章 创建和维护团队环境
本章提供了一些指导意见，帮助开发者创建团队的开发环境，总的来说，开发环境的创建包括以下几个方面：
● 开发工作台
● 一个Microsoft Visual SourceSafe服务器来来保存源代码控制数据库
● 一个备份服务器备份VSS的数据库
● 运行Microsoft SQL Server的计算机来开发和测试数据库
● Web服务器用来开发和测试网络服务
● 构架服务器，上面运行着自动创建的脚本完成日常的构架工作。
开发者也需要一个或多个独立的测试环境。例如，一个物理隔离的压力测试环境，它被用来进行可移植性和运行测试。关于测试环境的讨论不在本文范围之内，将来也不会对这个问题做过多的讨论。
一个团队开发环境的基础结构如图7.1所示。
图7.1 团队开发环境基础结构
创建一个开发域
为开发工作组定义一个开发环境并不是一个简单的任务。它需要为每一个用户账号和工作台创建现有的合作标准，并执行之。但是与此同时，开发人员也需要在他们自己的工作台上有一些特权，以此来实现以下目标：
● 安装更新或是操作系统的服务补丁
● 管理Microsoft Internet Information Services（IIS），以用作应用程序测试和精细调整。
● 调试ASP.NET网络应用程序
第一步是决定是将开发团队置于合作域还是置于个人独立的域中。这个问题没有简单的对或是错的答案。从更高的层次上来说，这个问题的决定取决于合作的安全策略。一个比较好的模型是开发团队成员都希望接受和为之付出的，同时也是能被现有的系统管理员良好维护的模型。具体的设计过程，可以参考以下的一些场景做为指导。
没有信任关系的独立的域
以下是一些使用没有信任关系的独立的域的一些特征：
● 这个模型提供最好的安全性，因为开发合作者不允许访问其它人员的开发环境。
● 一个独立的网络意味着，当管理员需要为容量计划运行加载测试时有足够的弹性和独立性。而且不需要担心影响重要的服务。
● 如果要使用合作域中的服务，例如，email和internet，开发者可以利用一个虚拟专用网络（VPN）连接到合作网络上。
● 管理员可以用Microsoft Window2000操作系统创建一个VPN服务器和路由以及远程访问服务器，或是可以配置Microsoft Internet Security和Acceleration（ISA）服务器，或是第三方的解决方案。
● 这个模型比较昂贵，因为需要独立的基础服务器－域控制器，DNS，WINS，DHCP等等（可能还需要额外的冗余配置）。
有信任关系的独立域
以下是一些使用有信任关系的独立的域的一些特征：
● 这个模型比较方便，因为不需要VPN的解决方案
● 如果管理员在开发域中设置了用户账号，那么合作域必须信任开发域，以此获得访问服务的权利，这有可能和使用者的安全策略相违背。合作用户不能访问开发环境。
● 如果管理员在合作域中设置开发用户账号，那么开发域必须信任合作域，这就为黑客提供了潜在的通道。
● 通过适当的计划和试验测试，大多数组织应该采用这种模型。
部分的合作域
以下是一些使用部分合作域的一些特征：
● 这是最方便的一种模型，因为没有域的分隔。
● 开发者可以利用所有现有的合作基础和服务
● 用户在合作安全策略下可能没有本地管理员的权限。这为开发者带来问题，因为开发者必须成为一个管理员才能在自己的开发工作台上调试ASP.NET的网络应用程序。
● 标准的合作网络和安全策略能隐藏开发过程。例如，开发者可能不被允许安装服务补丁，除非他们通过了合作操作模型
本章的余下部分描述了开发环境中每一台计算机所扮演的角色。
VSS服务器
这个服务器被用来保存一个或多个VSS数据库，这些数据库里包含所有开发人员的源控解决方案，工程文件和源文件。VSS服务器也是一个良好的Microsoft MSDN Library主机候选者，这个主机主要是为开发人员提供参考材料的。有关更多的信息，参见文章Q271776“ HOWTO：Create an MSDN Library Shared Install Point on the Network.”它位于Microsoft知识库中，网址是 http://search.support.microsoft.com/。
硬件需求
一个VSS服务器的最低推荐系统的硬件配置在VSS的readme文件里有详细叙述。然而，极少量的团队环境有可能需要一个更强有力的系统，近似于Visual Studio.NET开发工作台的推荐配置。这将在本章后面的“构架服务器”部分中详述。
值得注意的是：运行VSS数据库管理任务的时间很大程度上取决于处理器的速度和可供使用的RAM的大小。同时，硬盘的大小应该是数据库的大约两倍。
软件需求
VSS服务器上需要下列软件：
● VSS 6.0c版。它和Visual Studio.NET Enterprise Architect以及Enterprise Development一起发售。也可以从MSDN的CD或是DVD上获取，或是下载。
● 合适的备份软件。因为它VSS数据库在团队开发过程中的重要角色，所以它必须被有规律的备份。使用现有的备份软件备份VSS的数据库。
构架服务器
构架服务器控制创建脚本，并允许开发者生成个人系统的特殊版本。除了创建脚本之外，构架服务器也维护一套共享文件夹，它里面包含了最新创建操作的输出，以及以前的版本，这些通过创建版本号排列。这使得开发者可以参考最新的内部系统集合版本。
关于为什么开发者在一个团队开发环境中必须参考集合，参见第四章“管理依存关系”的相关章节“参考集合”。
一个推荐的规划创建输出的文件夹结构在第五章里描述了。本地的文件夹结构一般用来维护Visual Studio.NET的解决方案，工程和应该在跨服务器和开发工作台间保持一致的源文件。更多的相关信息，参见第三章“构架解决方案和工程”。
硬件需求
下面的列表是Visual Studio.NET构架服务器的最低推荐配置：
|
构架服务器 |
最低配置 |
|
CPU |
PentiumⅡ级别的处理器，450MHZ（推荐PentiumⅢ级别的处理器，600MHZ） |
|
内存 |
Microsoft Windows NT4.0 Workstation 64MB Windows NT 4.0 Server 160MB （推荐Workstation 96MB，Server192MB） Windows 2000 Professional 96MB Windows 2000 Server 192MB （推荐 Professional 128MB，Server 256MB） Windows XP Professional 160MB （推荐192MB） |
|
硬盘剩余空间 |
系统分区600MB，安装分区3GB |
|
驱动器 |
CD ROM |
|
显示 |
800×600， 256色（推荐真彩 16位色） |
|
操作系统 |
Windows 2000，Windows XP，WindowsNT4.0 |
|
外设 |
CD－ROM或是DVD－ROM，微软鼠标或是其它兼容设备 |
软件需求
下列是构架服务器的软件需求：
● Visual Studio.NET
● Visual SourceSafe6.0c(客户版)
● 其它系统需要的任何资源，例如IIS或是Message Queuing。
开发工作台
个人的开发工作台必须创建在稳固的文件系统文件夹结构之上，并且服务构架服务器的构架要求－特别是包含Visual Studio.NET解决方案和工程的文件夹。
使用镜像来创建开发工作台
要想在配置多个独立的开发工作台时节省时间，当安装完所有必须的应用程序和工具之后，可以考虑使用Sysprep.exe来创建一个工作台的镜像。开发者可以用第三方的磁盘镜像软件将这个镜像配置到其它电脑上。使用Sysprep.exe的优点是它有一个迷你的安装精灵，它能探测实际硬盘安装的这个新的工作台，然后处理硬件的不兼容，例如不同的视频适配器或是网络适配器。
推荐将所有的用户数据储存在一个独立的分区或是物理硬盘上（包括解决方案和工程）。使用这种方法，当要对镜像做一个大的更新时，可以在C区上重新安装镜像。同时开发者可以通过Windows 2000 Active Directory Service（活动目录服务）配置小的更新和一些额外的软件。
硬件需求
工作台必须满足Visual Studio.NET的最低推荐配置。因此，开发工作台和构架服务器有相同的硬件需求，这一点在本章的前面构架服务器的相关章节已经讨论过了。
软件需求
下列时开发工作台必须的一些软件：
● Visual Studio.NET
● Visual SourceSafe 6.0c客户组件
● SQL Server 2000 Development 版
● MSDN Library（客户版）
注意：如果开发工作台运行在Windows XP下，要确保安装了IIS以允许本地的网络开发。Windows XP的默认安装中不包括安装IIS。
Visual Studio Enterprise Templates
开发者可以使用Visual Studio Enterprise Templates来促进好的开发进程和标准的工程开发实践。它在大型分布式系统的开发环境下的应用效果更好，其时多个工程将用一个通用的应用程序构架创建。
Enterprise Templates提供的构架有三个功能，它们能帮助开发者更成功的创建基于.NET平台的应用程序：
1. 将一个现有代码和组件的建筑支持构架打包，并将其整合到Visual Studio.NET中去，它能给开发者提供一个熟悉的设计经验。构架者可利用这个功能提供应用程序的基础结构，这些结构在工程之间应该是通用且稳固的。
2. 捕捉构架和运行的法则，在开发者创建应用程序时，将它们用作活的指导。构架者可利用这些法则筛选出和工程目前不相关的项目。当开发者添加项目，参考，界面，类成员或是属性值到不合适的应用程序中时，这些法则还有迅速的提醒功能，这样就能避免一些常见的错误。
3. 帮助构架者实时提供给开发者相关的帮助主题，使得开发人员在编程前不必阅读海量的文献。
关于Enterprise Templates的更多信息，参见MSDN 图书馆中Visual Studio.NET部分的主题：“Enterprise Templates for Distributed Application”。
备份服务器
备份服务器用来备份VSS数据库的信息。开发者应该有规律的备份VSS的数据库（例如，每天）。
SQL服务器
这些系统中安装了SQL Server 2000 Enterprise Edition。当系统处于开发，支持或是维护状态时，它们被用来维护个人的数据库。
注意：一个个人的服务器可能被用来控制几个数据库，例如，一个整合测试和一个用户测试的数据库。这在很大程度上取决于开发者数据库的大小和服务器的容量。
关于怎样查询数据库版本问题以及为什么推荐开发者连接到这个服务器的问题，更多的信息参见第四章“管理依存关系”的相关章节“引用数据库”。
Web服务器
Web服务器控制目前在正在开发中的XML网络服务。当开发团队使用本地的IIS在本地工作台上开发网络服务时，Web服务器允许服务被中心发表，这样其它开发者或是开发团队能访问客户端的工程。关于使用网络服务的更多相关信息，参见第四章的相关章节。
在团队开发环境中的网路服务也被用来控制网络应用程序，从而支持整合，系统测试和用户测试。
操作系统需求
一个控制ASP.NET网络应用程序和网络服务以及Visual Studio.NET开发的网络服务的操作系统应该满足下列要求：
● Windows 2000，Windows XP或是Windows.NET Server。
● 同时推荐将Web服务器安装在一个文件系统是NTFS格式的硬盘上。
● Web服务器必须运行IIS5.0或是6.0.
关于进一步的细节，参见Visual Studio.NET CD1或是DVD上的setup\WebServer.htm。
安装和控制VSS
Visual Studio.NET Enterprise的盒子中单独提供了VSS6.0c的光盘，而且它并没有被默认安装到系统中。使用者必须自己在服务器上安装VSS，然后在需要访问VSS数据库的每一台计算机上安装客户端组件－这些数据库一般是开发工作台和构架服务器。
下面列出了用户安装VSS中需要采取的步骤：
在服务器上创建一个共享数据库
在服务器上运行Setup，然后选择共享数据库的安装。这个安装管理工具和网络安装程序（Netsetup.exe）允许VSS用户安装客户端软件。
用只读访问的模式共享VSS安装文件夹
用只读访问的模式共享VSS安装文件夹。这允许开发者从VSS文件夹中运行Netsetup.exe程序。注意默认的VSS安装文件夹是\Program Files\Microsoft Visual Studio\Vss。
至少为.NET Development工程创建一个新的数据库
使用VSS管理工具来为.NET development工程创建一个新的数据库。推荐用户创建一个新的数据库（而不是使用默认的那个）是因为这样用户就可以保证默认的数据库和管理工具（位于Vss\Win32目录下）独立。这样可以限制对管理工具的访问。大多数的用户应该被限制为只能访问新的数据库而不能访问管理工具。
不要在\Program Files目录下创建新的数据库，最好在独立的共享文件夹下创建新的数据库，如\VSS Databases.
考虑创建额外的VSS数据库
当一个数据库的规模达到5GB时，要考虑创建额外的数据库（在同一个服务器中，但是在不同的独立的共享文件夹下）。因为一旦数据库的规模达到5GB，管理工具就需要额外的时间（几个小时）来运行完成的工作。
也可以考虑为独立的开发工程使用独立的数据库。如果开发者将Visual Studio.NET的解决方案和工程分割成独立的VSS数据库，有以下优点：
通过对某些用户能访问的工程进行更精细的限定，系统的安全性能会大大提高。因为如果用户能够访问某一的VSS数据库，那么他就浏览和处理里面包含的任何一个工程。
一般的操作并不会涉及所有的工程。例如备份的维护需要数据库被锁定，这样才能防止通常（不是管理员）对数据库的访问。
如果用户曾经碰到数据库的损坏，管理员需要立即将数据库从网络上断开并修补这个错误。通过隔离数据库，只会影响到正在访问数据库的开发人员，而不会影响到其它人员。
当一个开发工程完成时，管理员可以很方便的访问工程的数据库。
共享数据库文件夹并创建适当的许可
共享新的数据库文件夹并允许VSS的用户享有完全的控制权限。VSS的用户包括开发者和一个自动创建过程的账号。
为所有能访问VSS开发数据库的用户创建一个Windows group。允许这个组的成员访问开发数据库，从而保护数据库文件夹。
不顾不希望用户有完全的控制权限，并且希望采取更强的控制措施，参见文章Q131022，”INFO: Required Newwork Rights for the SourceSafe Directories”，它在Mircosoft知识库中，网址是 http://search.suppotr.microsoft.com/
考虑使用VSS工程安全措施
考虑使用VSS管理工具来确保工程的安全并且从所有开发者中取消掉Destroy的功能。这就防止了开发者在VSS中永久性的删除某个工程。这样VSS的管理员可以恢复任何一个被开发者删除的工程。
如果工程安全性能选项处于使能状态，管理员必须将数据库中删除的项目彻底清除，以作为日常维护。虽然一个自动的维护脚本也能做到这一点。
关于默认的项目安全性能的更多信息，参见“Security Access Rights”它位于http://msdn.microsoft.com/library/default.asp?url=/library/en-us/guides/html/vstskSecurity_Access_Rights.asp.
为开发者和创建脚本添加用户账号
使用VSS管理工具打开新的数据库并向其中添加用户，并给每个用户适当的密码。
记住要个每一个开发者创建一个VSS用户，并给每个创建过程也要创建用户。如果处在域环境中，推荐用户名和域名相同。要确认网络名称被用作用户登录。在Tool菜单中，点击Options，然后选择Use network name for automatic user login的选项。
限制访问管理工具
创建一个Windows VSS管理组并使用这个组限制对VSS\Win32文件夹的访问。这个文件夹包括VSS的管理工具，管理员应该限制开发者访问这些工具。
发现并修补数据错误
VSS自带了诊断工具（它位于VSS\Win32文件夹下），这些工具能被用来检查和核对数据。管理员需要尽可能频繁的做这项工作－至少每月一次，推荐每周一次。分析检查所有VSS Data目录下的文件或是断开的链接，并且经常对这些问题做出改进。
下面是一些导致用户可能遇到数据库错误的原因。最常见的原因包括：
● 通常的网络问题，例如使用一个不可靠的远程链接和文件加载时中间断开。
● 磁盘空间不够。
虽然分析工作主要取决于数据库的内容和结构，但是这可能进展缓慢。例如大量的共享文件夹和子目录，以及文件的总数量。最好所有的用户在登出VSS之前都运行Analyze.exe。如果管理员使用F-switch来修补问题，用户必须登出。
注意：由于I/O的需要，通过在本地运行Analyze.exe而不是通过网络，可以极大的提高系统性能。同时要保证当前没有运行任何防病毒软件。
更多信息
关于Analyze.exe接受的命令行控制的完全列表，参见“Analyze”，它位于：
考虑安装Fault Tolerant Storage系统
独立磁盘冗余阵列（RAID）技术能将因错误访问硬盘而引起的数据损失降到最小。RAID是一个fault-tolerant磁盘配置模式，在这种模式下存储器中存储着数据的冗余信息。当一个硬盘或是访问路径发生错误或是磁盘上的某个扇区不能读取时，使用者可以使用这些冗余信息恢复数据。
● 对于操作系统和日志可以安装RAID Level1
● 对于数据和类似VSS的数据库可以安装RAID Level 5或是RAID 0+1
更多信息
关于怎样使服务器更加可靠的更多信息，参见下列资源：
在客户端安装VSS
要安装VSS客户端，只要在任何能够访问VSS（例如开发工作台或是构架服务器）的电脑上运行通过网络共享的Netsetup.exe就行了。这使得Visual Studio.NET IDE中的整合源控制特性能发挥作用。这也使得Source Control菜单中的File菜单处于使能状态。
考虑使用VSS影子目录
一个VSS阴影是中央服务器上映像一个VSS工程最新内容的目录。无论开发者何时在VSS工程中更新文件，它都被自动拷贝到影子目录中。
如果管理员希望有些不能访问VSS的用户能参考源代码，那么就可以考虑使用影子目录。例如，管理员可能希望开发团队的成员能够阅读源代码以帮助测试。
更多信息
关于Analyze.exe接受的命令行控制的完全列表，参见“Analyze”，它位于：
关于一般的VSS实例，参见“Microsoft Visual SourceSafe Best Practices”，它位于：
Microsoft有时也会更新Analyze工具，它包括更多检查，也提升了性能。有关Analyze的最新版本，请登录Microsoft Visual SourceSafe网站，它位于：
附录：
BuildIt——Visual Studio .NET的一个自动编译连接工具
概述：BuildIt是一个微软®.NET控制台应用软件，可以使patterns & practices中的文章——“使用Visual Studio .NET和Visual SourceSafe进行团队开发”中所描述的编译连接过程变得自动化，该文位于MSDN®库中的网页
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_ch5.asp上。
BuildIt由Sapient公司设计、开发和测试，由微软公司作出审查，涉及人员包括微软patterns & practices以及Visual Studio® .NET开发系统的团队成员。
使用BuildIt有以下好处：
● 不再需要花时间去创建、测试并且维护一个定制的编译连接脚本。
● 使得一个团队的编译连接过程变得更具可重复性和稳定性。
BuildIt被设计用来启动用于开发.NET分布式应用软件的编译连接过程。这个可下载的程序为微软Visual C#®开发工具和微软Visual Basic® .NET开发系统提供了完整的源代码和综合的文档。
注意：BuildIt当前支持编译连接解决方案，方案中包含了用Visual Basic .NET、Visual C#和Visual Studio .NET开发的安装项目，但是还没有用使用其它.NET语言编写的项目和其它安装项目（例如，Wise或InstallShield的安装项目）对其进行测试。
当BuildIt经过测试和审查，并且被认为是一个灵活、强健的代码集后，代码和文档将原原本本地提供出来，以供使用和扩展。
这个文档包括以下部分：
● 下载和安装BuildIt
● 对安装进行测试
● 用户指导
● 配置和操作
● 已知的问题
● 设计和实现
● 类引用
● 常见问题
● 附录小结
下载和安装BuildIt
要下载BuildIt，请访问网页http://microsoft.com/downloads/details.aspx?FamilyId=
B32497B0-77F7-4831-9C55-58BF3962163E&displaylang=en。安装过程将在您的Programs菜单中创建一个Microsoft Application Blocks for .NET子菜单。在Microsoft Application Blocks for .NET子菜单中，有一个Sapient BuildIt子菜单，包含了启动BuildIt Visual Studio .NET解决方案的选项。
对安装进行测试
以下步骤将对两个在Program Files\BuildIt\Code\BuildItTest中找到的解决方案例子进行编译连接，以帮助确认安装的BuildIt是否正常工作。
Ø 向源码控制中增加条目：
1. 在Visual SourceSafe®（VSS）版本控制系统中，创建一个名为BuildItTest的新项目。
2. 将$/BuildItTest上的工作文件夹设为Program Files\BuildIt\Code\BuildItTest。
3. 向VSS添加组件版本文件：
a. 向$/BuildItTest中添加
Program Files\BuildIt\Code\BuildItTest\AssemblyVersionInfo.cs。
b. 对于AssemblyVersionInfo.vb，重复上述过程。
4. 为网络项目（Project2）创建一个虚拟目录：
a. 浏览Program Files\BuildIt\Code\BuildItTest\Solution2\Project2。
b. 右击Project2，然后点击Properties。
c. 单击Web Sharing标签，然后点击Share this folder。
d. 接受缺省的别名，然后点击OK关闭Edit Alias对话框。
e. 点击OK关闭Properties对话框。
5. 向VSS添加解决方案：
a. 打开Program Files\BuildIt\Code\BuildItTest\Solution1\Solution1.sln。
b. 在解决方案浏览器中，右击Solution1，然后点击Add Solution to Source Control。
c. 浏览$/BuildItTest，然后单击OK（单击Yes创建VSS项目）。
d. 如果提示指定Project1的位置，浏览$/BuildItTest/Solution1，然后点击OK。
e. 对于Solution2，重复a-d的过程。
6. 在VSS中共享组件版本文件：
a. 向$/BuildItTest/Solution1/Project1共享$/BuildItTest/AssemblyVersionInfo.cs。
b. 向$/BuildItTest/Solution2/Project2共享$/BuildItTest/AssemblyVersionInfo.vb。
Ø 向项目中增加组件版本文件
1. 向Solution1中找到的Project1中添加AssemblyVersionInfo.cs：
a. 打开Program Files\BuildIt\Code\BuildItTest\Solution1\Solution1.sln。
b. 在解决方案浏览器中，右击Project1，指向Add，然后单击Add Existing Item。
c. 浏览Program Files\BuildIt\Code\BuildItTest\Solution1\Project1\AssemblyVersionInfo.cs，然后点击Open。
d. 在Check Out for Edit对话框，点击Check Out去校验Project1.csproj。
e. 打开AssemblyVersionInfo.cs，并且注意版本号（1.0.0.*）。
f. 按CTRL+SHIFT+B三个键，编译连接这个解决方案。
g. 在解决方案浏览器中，右击Project1，然后点击Check In Now（Recursive）。
h. 对于Solution2中找到的Project2，重复a-g过程将AssemblyVersionInfo.vb添加到该项目中。
2．更新配置设置项：
a. 打开Program Files\BuildIt\Code\BuildItTest\BuildIt.exe.config。
b. 更新sourceControl设置项。
3．配置BuildIt：
a. 打开Program Files\BuildIt\Code\BuildIt.sln。
b. 按CTRL+SHIFT+B三个键，编译连接这个解决方案（确认您所编译连接的是一个Release版本）。
c. 将.exe文件和所有的.dll文件从Program Files\BuildIt\Code\BuildIt\bin\Release拷贝到Program Files\BuildIt\Code\BuildItTest中。
4. 执行BuildIt并且检验：
a. 打开Program Files\BuildIt\Code\BuildItTest\BuildNumber.xml，并且注意下一个编译连接序号是1。
b. 打开Program Files\BuildIt\Code\BuildItTest\BuildIt.bat，检查BuildIt命令行。
c. 运行BuildIt.bat，编译连接这个解决方案。
d. 打开Program Files\BuildIt\Code\BuildItTest\BuildIt.log检查错误。
e. 打开Program Files\BuildIt\Code\BuildItTest\BuildReport.log检查编译连接的结果。
f. 打开BuildNumber.xml，并且注意下一个编译连接序号增加到2。
g. 打开AssemblyVersionInfo.cs和AssemblyVersionInfo.vb，并且注意到版本号从1.0.0.*更新为1.0.1.*。
h. 浏览Program Files\BuildIt\Code\BuildItTest\Archive\1，查看生成的组件是否被被存档到一个以编译连接序号命名的文件夹中。
i. 浏览Program Files\BuildIt\Code\BuildItTest\Latest，查看生成的组件是否被拷贝到最新的文件夹当中。
j. 显示$/BuildItTest的历史信息，查看VSS项目是否用编译连接序号做了标记。
用户指导
以下这些主题提供了关于使用BuildIt的更多信息：
● 维护编译连接序号
● 编译连接解决方案
● 检查编译连接报告
● 重新编译连接一个解决方案
● 归档编译连接
● 用电子邮件传送编译连接结果
● 版本化组件
维护编译连接序号
BuildIt使用编译连接序号去标记解决方案，这些解决方案在VSS中受到源码控制，并且由VSS更新组件版本号（如果选择了适当的编译连接选项）。在每一次成功的编译连接结束的时候，BuildIt通过把当前的编译连接序号加1来生成一个新的编译连接序号（如果编译连接失败，编译连接序号就不会增加）。然后新的编译连接序号被存储到一个XML文件中，该文件的名字和位置都在BuildIt.exe.config文件的buildNumberFilePath属性中得到定义。
以下的例子显示了一个名为BuildNumber.xml的编译连接序号XML文件的内容。
<buildNumber>1000</buildNumber>
注意：编译连接序号XML文件必须在运行BuildIt之前由一个起始编译连接序号创建并且进行初始化。
编译连接解决方案
BuildIt能够经过配置，可以编译单个解决方案和多个解决方案。对于包括跨解决方案的文件引用的多解决方案系统，解决方案必须以正确的顺序列出。例如，如果Solution2依赖于Solution1，请将Solution1列在Solution2的前面，以确保Solution1能够先行编译连接：
<solutions latestRootFolderFullName="c:\System"
buildNumberFilePath="c:\System\BuildNumber.xml">
<solution path="c:\System\Solution1\Solution1.sln"/>
<solution path="c:\System\Solution2\Solution2.sln"/>
</solutions>
检查编译连接报告
BuildIt在每次编译连接结束时生成一个编译连接报告，名为BuildReport.log，位于工作文件夹下。编译连接报告能够使用任意文本编辑器进行查看。编译连接报告包含了总结信息，并且提供了一个编译连接成功的解决方案列表和一个失败的解决方案列表。如果任何一个解决方案编译连接失败，可以使用Visual Studio .NET手动编译连接那些解决方案，以便查出究竟是什么原因导致它们编译连接失败。
=============================================
Build Report Generated by BuildIt
=============================================
Build Number: 8016
Build Start: 9/12/2002 6:50:09 PM
Build End: 9/12/2002 6:50:43 PM
Build Duration: 1 minute(s)
Archive Folder: c:\System\Archive\8016\
Latest Folder: c:\System\Latest\
Build Results: 1 succeeded, 0 failed
=============================================
Succeeded
=============================================
c:\System\Solution1\Solution1.sln
=============================================
Failed
=============================================
重新编译连接一个解决方案
在编译连接过程中，如果出现编译连接被中止的现象，一个rebuild选项就变成了必需的操作。您必须在重新编译解决方案之前完成下列步骤：
Ø 在编译连接中断之后重新进行编译连接
1. 如果修复过程需要修改代码，请从VSS中手动向编译连接计算机输出文件。
注意：在校验文件时，请使用编译连接工具配置文件中指定的同一个VSS证明信息。这有助于确定哪些文件需要修改，从而修复这个编译连接中断。
2. 更改代码，重新使用Visual Studio .NET进行编译，然后测试重编译后的文件。
3. 在问题解决之后，登记修改后的文件。
4. 使用前面的编译连接生成的标签去手动更新每一个登记的文件的标签，如下所述：
a. 右击文件名，然后点击Show History。
b. 在History Options对话框中，点击OK。
c. 点击想要更新标签的文件的版本，然后点击Details。
d. 用编译连接过程中使用过的标签更新Label域（例如，“Build 100”）。
5. 使用/rebuild选项，手动运行BuildIt。
归档编译连接
BuildIt经过配置，可以将先前的编译连接结果归档到一个指定的位置，就像“使用Visual Studio .NET 和Visual SourceSafe进行团队开发”一文中的“考虑维护先前的编译连接结果”部分所描述的那样。该文位于MSDN库的网页http://msdn.microsoft.com/library/en-us/dnbda
/html/tdlg_ch5.asp上。当archiveBuild编译连接选项被使能的时候，编译连接工具将拷贝生成的组件到一个文件夹当中，该文件夹以当前的编译连接序号命名，位于配置文件中archiveRootFolderFullName属性所指定的归档根文件夹的下面。
缺省情况下，BuildIt只归档由Visual C#和Visual Basic .NET项目生成的输出。为了归档其它项目，例如Visual Studio .NET安装项目的输出，请在additionalFoldersToArchive元素中增加folder元素。
以下这个来自BuildIt.exe.config的例子显示了如何使能这个选项。
<options>
<archiveBuild mode="on" archiveRootFolderFullName="c:\System\Archive">
<additionalFoldersToArchive>
<folder fullName=" c:\System\Solution1\Setup1\Debug"
destFolderName=“Debug\Setup1" />
<folder fullName=" c:\System\Solution1\Setup1\Release"
destFolderName=“Release\Setup1" />
</additionalFoldersToArchive>
</archiveBuild>
</options>
用电子邮件传送编译连接结果
BuildIt通过配置，可以使用电子邮件将编译连接结果传送到一个特定的e-mail地址，就如“使用Visual Studio .NET和Visual SourceSafe进行团队开发”一文中的“用电子邮件传送编译连接结果”部分所描述的那样，该文位于网页http://msdn.microsoft.com/library/en-us/dnbda
/html/tdlg_ch5.asp上。
当sendBuildReport编译连接选项被使能的时候，编译连接工具将发送一个生成的e-mail信息，它包含了一个名为BuildReport.log的编译连接报告，该信息被传送到一个由toAddress属性指定的e-mail地址当中。
以下来自BuildIt.exe.config的例子显示了如何使能这个选项：
<options>
<sendBuildReport mode="on" smtpServer="255.255.255.255”
toAddress="you@yourcompany.com"/>
</options>
版本化组件
BuildIt经过配置，可以使用存储在一个XML文件当中的当前编译连接序号去更新一个组件的版本号，该文件由buildNumberFilePath属性指定。就像下面所做的那样：
<solutions buildNumberFilePath="c:\System\BuildNumber.xml">
一个组件的版本号在典型的情况下由AssemblyVersion属性指定（该属性在AssemblyInfo.cs或AssemblyInfo.vb文件当中定义）。然而，当编译连接工具被配置为更新一个组件的版本号时，AssemblyVersion应该在一个单独的文件（例如，AssemblyVersionInfo.cs或AssemblyVersionInfo.vb）中定义，该文件在VSS中、在解决方案所有的.NET项目中共享。这就允许BuildIt更新一个文件，并且使得这个更改能够传播到解决方案的所有项目当中。关于更多的信息，请参阅“使用Visual Studio .NET和Visual SourceSafe进行团队开发”一文中的“考虑中心化组件版本号”部分，该文位于网页http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/dnbda/html/tdlg_ch5.asp上。
注意：两个名为AssemblyVersionInfo.cs 和AssemblyVersionInfo.vb的例子文件在BuildIt安装的时候被拷贝到BuildItTest目录下。
版本序号在物理上表现为一个分成四部分的数，每一部分用句点隔开，就像下面的例子代码所显示的那样：
<major version>.<minor version>.<build number>.<revision>
当updateAssemblyVersion编译连接选项被使能时，编译连接工具使用当前的编译连接序号去更新AssemblyVersion属性的build number部分。
下面来自BuildIt.exe.config的例子显示了如何使能这个选项。
<options>
<updateAssemblyVersion mode="on"
csAssemblyVersionVSSPath="$/System/AssemblyVersionInfo.cs"
vbAssemblyVersionVSSPath="$/System/AssemblyVersionInfo.vb" />
</options>
配置和操作
本部分包括了以下管理性主题：
● 部署BuildIt
● 配置BuildIt
● 保护BuildIt
● 解决BuildIt故障
部署BuildIt
当部署任何一个应用软件时，确定存在的依赖关系是非常重要的。BuildIt以一个名为BuildIt.exe的单一组件的形式出现，有着以下依赖关系：
● BuildIt.exe.config，用于配置设置项。
● BuildNumber.xml，用于维护下一个编译连接序号。
注意：编译连接序号XML文件的名字和位置在BuildIt.exe.config文件中的buildNumberFilePath属性中定义。同样请注意编译连接序号XML文件必须在运行BuildIt之前由一个起始序号创建并进行初始化。关于更多的信息，请参阅
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/emab-rm.asp上的“维护编译连接序号”部分。
● Microsoft.ApplicationBlocks.ExceptionManagent.dll和
Microsoft.ApplicationBlock.ExceptionManagent.Interfaces.dll，用于例外管理。
● Interop.SourceSafeTypeLib.dll，用于和VSS应用编程接口（SSAPI.dll）的互操作。
● Visual SourceSafe 6.0c客户程序，用于访问一个远程VSS数据库。
● Visual Studio .NET，用于编译连接.NET解决方案。
结合这个信息，可以针对开发团队的需要选择一个部署方法。对于BuildIt，有两个部署方法可以考虑：XCOPY或者是Windows安装程序。以下部分更为详细地描述了这两个选项。
用XCOPY进行部署
使用XCOPY部署BuildIt是最简单易行的方法；然而，它需要部署这个工具的人拥有较多的相关知识。要使用这个方法进行部署，请使用XCOPY将所需的组件和应用软件配置文件（BuildIt.exe.config）一道拷贝到目标计算机的一个目录中。接着，当它写Windows事件日志时，使用Installutil.exe系统组件去调用ExceptionManagerInstaller类，以便创建缺省的例外发布器所需要的事件源。例如，使用以下的命令行：
Installutil.exe Microsoft.ApplicationBlocks.ExceptionManagement.dll
关于更多例外管理应用软件模块的信息，请参阅MSDN库中的网页http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/emab-rm.asp上的“微软.NET应用软件模块”。
使用Windows安装程序进行部署
使用Windows安装程序部署BuildIt比起前面使用的XCOPY需要更多的工作量，但是它不要求部署这个工具的人有很多的相关知识。要使用Visual Studio.NET去安装和部署项目，请将BuildIt、Exception Management和Exception Management Interfaces的项目输出与BuildIt.exe.config文件一道添加到应用软件文件夹当中。然后，加入例外管理项目输出，这是一个定制操作，确保ExceptionManagerInstaller类在安装时能够初始化。
配置BuildIt
编译连接工具的行为可用一个应用软件配置文件进行控制。应用软件控制文件是基于XML的文档，存储在应用软件文件夹层次的根文件夹中。应用软件配置文件的名字具有applicationname.applicationextension.config的形式。对于编译连接工具，应用软件配置文件被命名为BuildIt.exe.config。
此部分包含了有关配置BuildIt的几个主题：
● 设置编译连接选项
● 配置跟踪功能
● 配置例外管理
● 运行多个版本的Visual Studio .NET。
注意：当配置文件被修改时，作出的改变不会立即生效，直到BuildIt再次执行为止。
设置编译连接选项
通过将选项的mode属性改成on或者off，您可以使能或者禁止任意一个编译选项，就如下面的例子代码所示：
<options>
<sendBuildReport mode="on" smtpServer="255.255.255.255"
toAddress="you@company.com"/>
</options>
注意：如果mode属性被省略了，或者有其它不同于on/off的值，一个例外就产生了。同样要注意mode属性的值是大小写不敏感的。
配置跟踪功能
BuildIt使用System.Diagnostics域名空间中的Trace类生成跟踪输出，这些输出被写到控制台和工作目录下一个名为BuildIt.log的文件当中。以下是一个跟踪输出的例子。
Validating command-line arguments
Reading BuildIt settings from configuration file
Starting build 100 at 11/1/2002 1:57:53 PM
Updating assembly version file $/System/AssemblyVersionInfo.cs
Labelling source
Getting source from label
Backing up latest folder
Building Debug version of solution C:\System\Solution1\Solution1.sln
Building Release version of solution C:\System\Solution1\Solution1.sln
Building Debug version of solution C:\System\Solution2\Solution2.sln
Building Release version of solution C:\System\Solution2\Solution2.sln
2 solution(s) succeeded, 0 failed
Deleting latest backup folder
Archiving additional folders
Generating build report
Not sending build report because the option was not enabled
Ending build at 11/1/2002 1:58:40 PM - 0 minute(s) to complete
可以使用一个BuildIt.exe.config文件中定义的名为traceLevel的跟踪开关使能或者禁止跟踪功能。如果将跟踪开关设为0，则跟踪功能被禁止，否则，如果设为3，则跟踪功能被使能。将跟踪开关设为4允许更详细的跟踪输出（详细模式）。
下面的例子代码显示了如何使能跟踪功能。
<system.diagnostics>
<switches>
<add name="traceLevel" value="3"/>
</switches>
</system.diagnostics>
除此之外，BuildIt经过配置，可以将跟踪输出附加到跟踪文件的后面（如果该文件已经存在），或者可以使当前的跟踪输出覆盖掉跟踪文件。推荐的设置是覆盖掉跟踪文件，以防止它变得过大。下面的例子代码显示了如何实现上述的设置。
<appSettings>
<add key="appendTraceOutput" value="off" />
</appSettings>
注意：如果appendTraceOutput键值被省略的话，BuildIt的缺省操作是覆盖跟踪文件。
配置例外情况管理
BuildIt使用微软的例外管理应用软件模块，该模块可以在配置文件中用XML设置项进行配置。如果该设置项被省略，例外管理应用软件模块将缺省地向应用软件日志文件中发布例外情况。然而，也可以指定另外的发布者。
在编写此文档的时候，配置文件不包含例外管理设置项。因此，所有的例外情况被发布到应用软件日志中，该日志可以使用事件阅览器进行查看。关于更多的信息，请参阅MSDN库中的“例外管理应用软件模块概述”，位于网页http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/dnbda/html/emab-rm.asp上。
运行多个版本的Visual Studio .NET
缺省情况下，BuildIt使用最后安装的Visual Studio .NET版本去编译连接解决方案。然而，如果在同一个计算机上安装了多个版本，开发人员可以指定BuildIt去使用一个特定的版本。为了强制BuildIt使用Visual Studio .NET的某个特定版本，请在配置文件的appSettings部分包含一个visualStudioProgID键值。下面的例子代码显示了如何完成上述操作。
<appSettings>
<add key="visualStudioProgID" value="VisualStudio.Solution.7" />
</appSettings>
注意：如果visualStudioProgID键值被省略，则BuildIt将缺省使用安装的Visual Studio .NET的最新版。
保护BuildIt
就跟任意一个应用软件一样，您必须确保所有的敏感数据和资源能够得到保护，确保它们不会受到未经授权的访问。考虑到BuildIt的具体情况，有两个主要的方面需要考虑：
● 保护应用软件配置文件，使其不受到未授权访问
● 设置BuildIt所需的访问权限
保护配置文件不受到未授权访问
因为编译连接工具配置文件包含了敏感数据，例如VSS的用户名和密码，您应当确保只有授权用户能够看到并且改变这些设置项。您可以使用Windows NTFS文件许可保护配置文件。
设置BuildIt所需要的访问权限
BuildIt使用微软例外管理应用软件模块向事件日志中发布例外情况。除此之外，BuildIt还读写文件系统。因此，您需要确保BuildIt使用的安全准则拥有适当的权限去完成这些操作。
解决BuildIt故障
有两个可用的机制可用来帮助开发者解决此编译连接工具的故障：
跟踪和例外管理。当跟踪功能被使能时，BuildIt在工作目录下生成一个跟踪文件，名为BuildIt.log，可被用来决定哪一步应当由编译连接工具执行。在试图找出编译连接工具的行为为何不符合预期情况的原因时，这是非常有用的。
当一个例外发生时，BuildIt使用微软的例外管理应用软件模块向应用软件日志中发布例外情况。开发人员能够使用事件阅览器去查看关于这个例外的详细信息。这两个机制一起使用时，可以提供能够用于解决编译连接故障的信息。
已知问题
BuildIt在大多数场合中是非常有效的，但是在某些情况下，它也有一些已知的问题。表1列出了BuildIt的一些已知问题。
表1：BuildIt的已知问题
|
问题 |
描述 |
解决方法 |
|
在编译两个或多个拥有相同项目名的解决方案时，BuildIt会产生一个错误。 |
当BuildIt试图将项目输出拷贝到最新的文件夹当中，而输出又早已存在的情况下，BuildIt就会产生一个错误。这种情况在BuildIt遇到两个相同的项目名时可能发生，尽管它们可能位于不同的解决方案当中。在BuildIt的单次运行中，如果它两次遇到同一个解决方案，这种情况也可能发生。 |
确保您的系统中所有项目的命名都是独一无二的，并且保证app.config文件不包含重复的解决方案条目。 |
|
在编译连接过程中Set Project Location对话框出现 |
在编译连接过程中Set Project Location对话框出现，提示用户输入一个网络项目的工作拷贝的位置。当试图载入一个没有映射到相应的虚拟目录的网络项目时可能发生这种情况。 |
为了防止此对话框在BuildIt运行的时候出现，确保在运行BuildIt之前，所有的网络项目都映射到虚拟目录当中。一个较为容易的检验方法是在运行BuildIt之前，在Visual Studio .NET中手动打开每一个解决方案。 如果BuildIt运行的时候对话框真的出现，只需要通过设置网络项目的工作拷贝的位置对对话框作出回应。Visual Studio .NET然后会自动地建立虚拟目录。 |
设计和实现
本部分包括了以下一些关于设计和实现的主题：
● 问题描述
● 设计目标
● 解决方案描述
● 改进和提高
问题描述
BuildIt被设计用来解决以下的问题：
● 开发人员将宝贵时间花在了创建、测试和维护定制的编译连接脚本上，而这些脚本通常是不可重用的。
● 开发人员的时间通常十分紧张，没有多少时间可用于编译连接脚本的全面测试和编写文档的工作。
设计目标
BuildIt的设计目标是：
● ●解决方案必须遵循文章“使用Visual Studio .NET和Visual SourceSafe进行团队开发”中所描述的步骤，该文位于MSDN库当中的网页http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_ch5.asp上。
● 解决方案必须有良好的文档组织，是可维护的，并且还应当是易于使用的。
● 解决方案必须是灵活的；它应当是可配置的，而不需要重新编写代码和重新编译。
● 解决方案必须是强健的；它必须能够处理在编译连接过程中产生的任何例外情况。
解决方案描述
BuildIt是一个控制台应用软件，由许多的类组成，这些类协同工作，使得编译连接的过程变得自动化。例如：
● BuildInitializer。检验命令行选项，通过BuildItSectionHandler获取编译连接工具的设置项，并且通过BuildManager初始化编译连接过程。
● BuildItSectionHandler。从工具配置文件中获取设置项。这些设置项被用于改变运行期行为。
● BuildManager。组织安排编译连接过程。
● SourceSafeHelper。在编译连接过程中使用，显示VSS操作（例如，登记和校验）。
● BuildItResourceManager。对存储在一个资源文件中的错误信息提供类型安全的访问。
● BuildItCommandLineArgs。封装BuildIt所支持的命令行参数。
图1显示了这些类是如何协同工作的。
图1 编译连接过程流图
逻辑流程如下所述：
2. Main1类调用BuildInitializer类的Start方法。
3. BuildInitializer类检验命令行参数，然后使用BuildItSectionHandler类从工具的配置文件中获取设置项。BuildItSectionHandler通过名为BuildItSettings的类型安全结构返回设置项。
4. BuildInitializer创建BuildManager的一个实例，将BuildItSettings结构传送到Constructor。
5. BuildInitializer然后调用BuildManager的Build方法，根据相应的命令行参数去初始化一个编译连接或一个重新编译连接。
配置文件设置项
BuildIt配置文件，称为BuildIt.exe.config，包含了在运行期读取的设置项。这允许工具的行为可被修改，而无需重新编译解决方案。
文件中的设置项指示了：
● 解决方案正在被编译连接。
● 需要一些连接到一个指定的VSS数据库的信息。
● 是否用编译连接序号去更新组件版本。
● 是否归档先前的编译连接组件到一个特定的位置。
● 是否将编译连接结果通过一个e-mail消息传送到一个指定的e-mail地址中。
注意：如果任何一个设置项发生遗失或出现特定错误，BuildIt将生成一个例外，除非在文档中作了特别的说明。
以下的例子代码显示了配置文件设置项的格式：
<configuration>
<configSections>
<section name="BuildIt"
type="Sapient.Framework.Tools.BuildIt.BuildItSectionHandler,
BuildIt"/>
</configSections>
<appSettings>
<add key="appendTraceOutput" value="off" />
<add key="enableCustomMessageFilter" value="on"/>
<add key="visualStudioProgID" value="VisualStudio.Solution.7"/>
</appSettings>
<buildIt>
<sourceControl username="username" password="password"
iniFilePath="c:\Program Files\Microsoft Visual Studio\VSS\srcsafe.ini"
srcVSSRootFolder="$/System" srcFileRootFolder="c:\System"/>
<solutions latestRootFolderFullName="c:\System"
buildNumberFilePath="c:\System\BuildNumber.xml">
<solution path=" c:\System\Solution1\Solution1.sln"/>
<solution path=" c:\System\Solution2\Solution2.sln"/>
</solutions>
<options>
<sendBuildReport mode="on/off" smtpServer="255.255.255.255"
toAddress="you@yourcompany.com"/>
<archiveBuild mode="on/off"
archiveRootFolderFullName="c:\System\Archive">
<additionalFoldersToArchive>
<folder fullName="c:\System\Solution1\Setup1\Debug"
destFolderName=“Debug\Setup1" />
<folder fullName=" c:\System\Solution1\Setup1\Release"
destFolderName=“Release\Setup1" />
</additionalFoldersToArchive>
</archiveBuild>
<updateAssemblyVersion mode="on/off"
vbAssemblyVersionVSSPath="$/System/AssemblyVersionInfo.vb"
csAssemblyVersionVSSPath="$/System/AssemblyVersionInfo.cs"/>
</options>
</buildIt>
</configuration>
ConfigSections元素
configSections元素被用于将配置文件中的一个部分和一个特定的配置部分处理类连接起来。上面代码中Section元素被用于连接BuildIt部分和Sapient.Framework.Tools.BuildIt域名空间中的BuildItSectionHandler类。
AppSettings元素
appSettings元素包含了应用软件特定的设置项，该设置项能够表述为键值对。当前，BuildIt定义了三个设置项：
● ●appendTraceOutput。但这个键值被设为on时，BuildIt将跟踪输出附加到名为BuiltIt.log的跟踪文件后面。
注意：如果这个键被省略或者值没有设成on，BuildIt就会覆盖掉跟踪文件。
● ●enableCustomMessageFilter。当这个键值被设成on时，BuildIt使能一个定制的消息过滤器，在等待一个同步调用的应答时处理流出的COM消息。这个过滤器的实现在对象处于“繁忙状态”的事件中重新尝试调用之前拒绝被调用的Visual Studio .NET自动化组件。如果Visual Studio .NET自动化对象处于繁忙状态，并且这个过滤器没有被使能，一个例外情况就会产生。
注意：如果这个键被省略或者值没有设成on，BuildIt将禁止消息过滤器。
● ●visualStudioProgID。当这个键值被设成一个progID时，BuiltIt.NET将不得不在编译连接解决方案时使用一个指定版本的Visual Studio .NET。
注意：如果这个键被省略，BuildIt将使用Visual Studio .NET的最新安装版本。
SourceControl元素
sourceControl元素包含了在编译连接过程中使用的VSS数据库的信息。这个元素具有以下属性：
● 用户名。VSS用户用于登录到数据库的名字。
● 密码。VSS用户的密码。
● iniFilePath。VSS的.ini文件路径，用于定位数据库（例如，C:\Program Files\Microsoft Visual Studio\VSS\srcsafe.ini）。
● srcVSSRootFolder。VSS根文件夹，包含了正要进行编译连接的源代码（例如，$/System）。BuildIt从这个VSS项目中进行递归的Get操作。
● srcFileRootFolder。文件系统根文件夹，源代码在这里被编译连接（例如，C:\System）。BuildIt通过递归的Get操作将文件拷贝到这个目录底下。
Solutions元素
solutions元素包含了正在编译连接的解决方案的信息。这个元素具有以下属性：
● latestRootFolderFullName。根文件夹的名字（例如，C:\System），这个文件夹包含了编译连接完成之后最新生成的组件。关于更多信息，请参阅文章“使用Visual Studio .NET和Visual SourceSafe进行团队开发”中的“将输出拷贝到最新的文件夹”部分，该文位于MSDN库的网页http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda
/html/tdlg_ch5.asp上。
注意：MSDN库中的文章“使用Visual Studio .NET和Visual SourceSafe进行团队开发”，位于网页http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_ch5.asp上，叙述了“单解决方案和分块单解决方案系统不需要一个最新的文件夹，因为您使用项目引用而不是文件引用去引用组件”。然而，因为一个单解决方案系统可以变成一个多解决方案系统，BuildIt总是将编译连接输出拷贝到一个最新的文件夹当中。这就允许开发人员在引用由另外一个解决方案生成的组件时使用文件引用。
● ●buildNumberFilePath。这个XML文件用来生成下一个编译连接序号（例如，C:\System\BuildNumber.xml）。关于更多的信息，请参阅文章“使用Visual Studio .NET和Visual SourceSafe进行团队开发”中的“创建编译连接版本号”部分，该文位于MSDN库的网页http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_ch5.asp上。
注意：位于http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_ch5.asp上的文章“使用Visual Studio .NET和Visual SourceSafe进行团队开发”没有规定编译连接序号产生的方法。BuildIt规定，在每次成功的编译连接结束时，增加存储在一个指定的XML文件中的编译连接序号。一次成功的编译连接指的是没有发生任何错误的编译连接。
Solution元素
solution元素包含了一个特定的解决方案的信息。这个元素有一个属性：
● ●path。正在编译连接的解决方案文件（例如，C:\System\Solution1\Solution1.sln）。
Options元素
Options元素包含了对应于不同编译连接选项的子元素。每一个编译连接选项都用一个不同的元素加以表述。
SendBuildReport元素
sendBuildReport元素控制了在编译连接完成时编译连接报告是否被送到一个指定的e-mail地址。关于更多的信息，请参阅文章“使用Visual Studio .NET和Visual SourceSafe进行团队开发”中的“用电子邮件传送编译连接结果”部分。该文位于MSDN库的网页http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_ch5.asp上。
这个元素包含了以下属性：
● Mode。如果是“on”，BuildIt将编译连接报告发送到指定的e-mail地址。
● smtpServer。决定SMTP服务器的IP地址是否被用于转发e-mail消息。
● toAddress。接收编译连接报告的e-mail地址。
Archive Build元素
archiveBuild元素控制了生成的组件是否被归档到一个以编译连接序号命名的文件夹当中。关于更多的信息，请参阅文章“使用Visual Studio .NET和Visual SourceSafe进行团队开发”中的“考虑维护先前的编译连接结果”部分。该文位于MSDN库中的网页http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_ch5.asp上。
这个元素包含了下列属性：
● mode。如果是“on”，BuildIt将生成的组件拷贝到一个以编译连接序号命名的文件夹当中。
● archiveRootFolderFullName。包含先前的归档编译连接结果的根文件夹的名字（例如，C:\System\Archive）。
Additional Folders to Archive元素
缺省情况下，BuildIt仅从Visual C#和Visual Basic .NET项目中归档输出。为了从其它项目例如Visual Studio .NET安装项目中归档输出，请向additionalFoldersToArchive中添加folder元素。
Folder元素包含下列属性：
● fullName。正在归档的源文件夹的全名（例如，C:\System\Solution1\Setup1\Debug）。
● destFolderName。用于归档的目标文件夹的名称（例如，Debug\Setup1）。
注意：如果archiveBuild选项被使能，BuildIt归档每一个指定文件夹中的文件到归档根文件夹下的指定目标文件夹中。
UpdateAssemblyVersion元素
updateAssemblyVersion元素控制了生成的组件是否使用编译连接序号进行版本编号。关于更多的信息，请参阅文章“使用Visual Studio .NET和Visual SourceSafe进行团队开发”中的“控制组件版本号”部分。该文位于MSDN库中的网页http://msdn.microsoft.com
/library/default.asp?url=/library/en-us/dnbda/html/tdlg_ch5.asp上。
这个元素包含下列属性：
● Mode。如果是“on”，BuildIt将生成的组件使用编译连接序号进行版本编号。
● vbAssemblyVersionVSSPath。这个VSS路径包含了组件版本号文件，这个文件在所有将要编译连接的Visual Basic .NET项目中共享（例如，$/System/AssemblyVersionInfo.vb）。如果您的解决方案不包括任何Visual Basic项目，请保留这个属性值为空。关于更多信息，请参阅文章“使用Visual Studio .NET和Visual SourceSafe进行团队开发”中的“考虑中心化组件版本号”部分。该文位于MSDN库中的网页http://msdn.microsoft.com/library
/default.asp?url=/library/en-us/dnbda/html/tdlg_ch5.asp上。
● csAssemblyVersionVSSPath。这个VSS路径包含了组件版本号文件，该文件在所有将要编译的Visual C#项目中共享（例如，$/System/AssemblyVersionInfo.cs）。如果您的解决方案当中不包含任何一个Visual C#项目，请保留这个属性值为空。关于更多信息，请参阅文章“使用Visual Studio .NET和Visual SourceSafe进行团队开发”中的“考虑中心化组件版本号”部分。该文位于MSDN库中的网页http://msdn.microsoft.com/library
/default.asp?url=/library/en-us/dnbda/html/tdlg_ch5.asp上。
改进与提高
这个部分包含了一个列表，它包括了已经考虑到但最终由于时间限制没有在BuildIt的第一个发布版本中实现的需要改进之处。这些信息是共享的，显示了与BuildIt的开发过程有关的潜在的想法，对于在何处能够对BuildIt进行扩展作出了建议，并且邀请您作为这个团体的一员提出自己的想法——和代码——请使用本文档结束处的反馈部分。潜在的改进包括：
● 定义一个接口，允许BuildIt和源码控制提供者而不是Visual SourceSafe一起工作（例如，ISourceControlProvider）。这样，开发人员就能够对BuildIt进行配置，使它可以使用其它源码控制提供者的产品，例如，Rational ClearCase。
● 如果一个特定的设置项发生丢失，可以通过实施缺省行为来简化BuildIt的配置。目前，如果应用软件配置文件中的一个特定的编译连接选项发生遗失，BuildIt就会生成一个错误。一个更加易用的BuildIt版本在一个设置项被省略的情况下将会简化一些缺省行为。
● 通过组件相关路径而不是使用完整路径进一步简化BuildIt的配置。目前，所有的文件路径都必须是完整路径。完整路径比相对路径更具灵活性，但是也比后者更为麻烦。相反，可以通过使一些路径相对于源根文件夹来简化配置（例如，解决方案文件、编译连接序号XML文件等等）。
● 允许开发人员使用updateAssemblyVersion编译连接选项去指定一个不确定的组件版本号文件。目前，BuildIt允许开发人员指定一个Visual C# 和一个Visual Basic .NET组件版本号文件。这个限制是基于开发人员将会通过VSS在所有的Visual C#项目中共享Visual C#组件版本文件、在所有的Visual Basic .NET项目中共享Visual Basic .NET组件版本文件的假定上的。然而，开发人员更倾向于更新个别组件版本文件，而不是依赖于VSS的文件共享。
● 定义一个“后编译连接”事件，开发人员可以用来扩展编译连接过程。目前，扩展编译连接过程的唯一方法是改变BuildIt的源代码。一个更加灵活的设计将是执行在编译连接过程将要结束时引发的一个事件。开发人员然后可以给这个事件绑定事件处理程序，使它执行定制的逻辑。这个策略可用于允许开发人员定制编译连接过程的其它部分（例如，预编译连接，编译连接和后编译连接）。
● 允许开发人员指定BuildIt配置文件的名称。目前，BuildIt在名为BuildIt.exe.config的标准的应用软件配置文件中查找配置设置项。因为这样，开发人员不能同时使用BuildIt去编译连接两个不同的解决方案。相反，开发人员必须将BuildIt组件拷贝到一个不同的文件夹当中。一个更加友好的解决方法是允许开发人员指定配置文件的名称，作为一个命令行参数，而不是使用标准的应用软件配置文件。
● 使BuildIt自动地为任意一个还未映射到虚拟目录的网络项目创建一个虚拟目录。目前，Visual Studio .NET提示用户设置一个网络项目的工作拷贝的位置，如果该位置事先不存在的话。不再提示用户接受缺省设置，BuildIt能够自动地简化虚拟目录的创建过程。
类引用
本部分包括了关于下述类引用的信息：
● BuildInitializer
● BuildItSectionHandler
● BuildManager
● SourceSafeHelper
● BuildItResourceManager
● BuildItCommandLineArgs
BuildInitializer
BuildInitializer类检验命令行选项，通过BuildItSectionHandler获取编译连接工具设置项，并且通过BuildManager初始化编译连接过程。
注释
BuildInitializer类实现了一个简单的公共方法，名为Start，为控制台应用软件的static/Shared Main方法所调用。Start方法首先通过调用一个名为AreCommandLineArgsValid的方法检验任意一个命令行参数。如果参数是合法的，BuildInitializer使用BuildItSectionHandler类获取编译工具设置项。最后一个步骤是通过调用BuildManager中的Build方法来初始化编译连接过程。
构造函数
|
BuildInitializer |
初始化BuildInitializer类的一个实例 |
公共方法
|
Start |
使用BuildItSectionHandler类从编译连接工具配置文件中读取配置项，并且通过BuildManager类启动编译连接过程。 |
私有方法
|
AreCommandLineArgsValid |
判断给定的命令行参数是否合法。 |
|
IsCommandLineArgsValid |
判断给定的命令行参数是否合法 |
|
usage |
编写控制台的使用信息。当任何一个命令行参数不合法时被调用。 |
BuildItSectionHandler
BuildItSectionHandler类使用从编译连接工具配置文件中读取的设置项来组成和返回一个BuildItSettings结构。
注释
BuildItSectionHandler类实现了IConfigurationSectionHandler接口，解析编译连接工具配置文件中的BuildIt的配置设置项。它把BuildIt元素的信息载入到一个名为BuildItSettings的结构中。
BuildItSettings结构定义了几个属性，对配置文件中定义的配置设置项提供了类型安全的访问。例如，BuildItSettings结构定义了三个属性，返回不同的编译连接选项：OptionSendBuildReport、OptionArchiveBuild和OptionUpdateAssemblyVersion。BuildItSettings结构也定义了一个名为Solutions的属性和一个名为SourceControlInfo的对应于配置文件中特定元素的属性。
构造函数
|
BuildItSectionHandler |
初始化BuildItSectionHandler类的一个实例 |
公共方法
|
Create |
使用从编译连接工具配置文件中读取的设置项来组成和返回一个BuildItSettings结构 |
私有方法
|
CreateBuildOption |
使用从编译连接工具配置文件中读取的设置项来创建和组成一个BuildOption结构 |
BuildManager
BuildManager类组织安排编译连接过程。
注释
BuildManager类被BuildInitializer用来调整编译连接过程。BuildManager实现了一个构造函数，具有两个参数：一个是BuildItSettings类型的，另一个是BuildItResourceManager类型的。当BuildManager类的一个实例被创建时，它使用传递给它的构造函数的参数去初始化私有成员函数。这使得设置项和错误消息在编译过程中对于BuildManager而言变得可用。
BuildManager也提供了一个公共方法，名为Build，它使用一个BuildType枚举变量去判断是初始化一个编译连接还是初始化一个重新编译连接。BuildType枚举变量的定义如下所述：
[C#]
public enum BuildType {Build, Rebuild};
Rebuild被定义为在一个编译连接中断被修复后发生的系统编译连接。Build和Rebuild的差别在于在进行重新编译连接时，一些步骤是被省略的。例如，BuildManager在进行编译连接时在VSS中创建一个新的标签，但是在重新编译连接时就不这样做。
在BuildTyp被决定之后，BuildManager调用几个私有方法去执行编译过程的不同部分。
构造函数
|
BuildManager |
初始化BuildManager类的一个新实例 |
公共方法
|
Build |
组织安排编译连接过程 |
私有方法
|
ArchiveAdditionalFolders |
将编译连接工具配置文件中additionalFoldersToArchive部分指定的文件夹的内容拷贝到归档根文件夹中。 |
|
BackupLatestFolder
|
备份包含最新生成的组件的最新文件夹。这个文件夹的位置在编译连接工具配置文件中指定。 |
|
BuildAssemblyVersionRegEx
|
编译连接一个常规表达式，该表达式被用于取代AssemblyVersion属性的编译连接序号组件。这个表达式取决于AssemblyVersion属性是一个Visual Basic属性还是一个Visual C#属性。 |
|
BuildSolutionAndCopyOutput
|
编译连接一个解决方案并且将产生的输出拷贝到指定的目标目录下。 |
|
BuildSolutionConfig
|
使用指定的编译连接配置（例如，发布、调试等等）去编译连接给定的解决方案。 |
|
BuildSolutions
|
编译连接给定的解决方案。 |
|
CopyFiles(string, string)
|
通过调用重载版本的这个方法，同时将excludeDebugFiles标志设为false，从而将所有的文件从给定的源文件夹拷贝到给定的目标文件夹中。 |
|
CopyFiles(string, string, bool)
|
从给定的源文件夹拷贝所有的文件到给定的目标文件夹中。如果excludeDebugFiles标志设为true，就拷贝除调试文件之外的所有文件。 |
|
CopyVSProjectOutput
|
拷贝所有的Visual Basic和Visual C#项目输出（发布或者调试）到给定的目标根文件夹当中。 |
|
CopySolutionOutput
|
拷贝解决方案输出（发布或者调试）到给定的目标根文件夹当中。 |
|
DeleteArchiveFolder
|
删除归档文件夹，如果存在的话。归档文件夹的位置在编译连接工具配置文件中指定。 |
|
DeleteLatestBackupFolder
|
删除最新的备份文件夹，如果存在的话。最新的备份文件夹与最新文件夹位于同一个位置。 |
|
DeleteLatestFolder
|
删除最新文件夹，如果存在的话。 |
|
GenerateBuildReport
|
生成一个名为BuildReport.log的编译连接报告，并且将这个报告存储到工作文件夹当中。 |
|
GenerateLabel
|
基于编译连接序号生成一个标签。 |
|
GetSourceFromLabel
|
使用给定的标签从VSS中得到源根项目。 |
|
GetVSProjectLangType
|
判断用于创建指定文件的语言（Visual Basic或Visual C#）。使用文件扩展名去作出判断。 |
|
IncrementBuildNumber
|
将编译连接序号加1，然后通过调用WriteBuildNumber将它写进编译连接序号XML文件。 |
|
LabelSource
|
在VSS中用给定的标签去标注源根项目。 |
|
ReadBuildNumber
|
从编译连接序号XML文件中读取编译连接序号。这个文件的名字和位置在编译连接工具配置文件中指定。 |
|
RestoreLatestFolder
|
从最新的备份文件夹中恢复最新文件夹，如果前者存在的话。 |
|
SendBuildReport
|
将编译连接报告发送给正确的email接受者，如果该选项在编译连接工具配置文件中被使能的话。 |
|
UpdateAssemblyVersionInfo
|
得到Visual Basic和Visual C#组件文件的VSS路径（在编译连接工具配置文件中指定），并且为每一个文件调用一次重载版本的该方法，如果该选项在编译连接工具配置文件中被使能的话。 |
|
UpdateAssemblyVersionInfo(string)
|
从VSS中得到指定的AssemblyVersion文件，使用一个通用表达式，用编译连接序号去更新AssemblyVersion属性，然后将这个文件登记到VSS中。 |
|
WriteBuildNumber
|
向编译连接序号XML文件写入给定的编译连接序号。 |
SourceSafeHelper
SourceSafeHelper封装了VSS自动化对象，使它更容易和VSS协同工作。
注释
SourceSafeHelper类被BuildManager用于在编译连接过程中和VSS进行交互。它提供了几个公共方法，例如Checkin和Checkout，这些方法隐藏了与VSS自动化对象协同工作的实现细节。
注意：SourceSafeHelper类并不对每一个VSS操作都提供方法。它只为编译连接工具所需要的那些操作提供方法。
构造函数
|
SourceSafeHelper |
初始化SourceSafeHelper类的一个新实例 |
公共方法
|
Checkin |
向VSS中登记文件 |
|
Checkout |
从VSS中校验给定的条目 |
|
GetFromLabel |
从VSS中取得一个特定版本的给定条目。如果该条目是项目，则获取操作是递归的。 |
|
Label |
用指定的标签标注给定的VSS条目。 |
|
UndoCheckout |
取消一个给定的VSS条目的checkout状态。 |
私有方法
|
GetItemsRecursively |
从一个版本化的VSSItem（一个项目或文件）中递归地获取条目。这个版本化的条目可以是一个项目或是一个文件。如果VSSItem是一个文件，这个方法只是简单地获取文件。否则，它递归地从项目中获取所有的条目。 |
|
GetVSSItem
|
获取一个指向VSSItem（即一个项目或文件）的引用。 |
BuildItResourceManager
BuildItResourceManager类提供对存储在一个资源文件中的错误消息的类型安全的访问。
注释
BuildItResourceManager类，由System.Resources域名空间的ResourceManager类中派生，被用于从名为BuildIt.exe的编译连接工具组件的资源文件中获取错误消息。它提供了几个公共方法，例如GetBuildSolutionFailedString，提供了对资源值的类型安全的访问。这有助于消除使用一个不合法的资源名去调用ResourceManager.GetString(string name)方法而产生的错误。
构造函数
|
BuildItResourceManager |
初始化BuildItResourceManager类的一个新实例 |
公共方法
|
GetBuildSolutionFailedString |
从编译连接工具资源文件中获取BuildSolutionFailed错误消息。获取方法的其它部分执行一个相似的功能；它们为存储在编译连接工具资源文件中的错误信息提供了类型安全的访问。 |
私有方法
|
None |
|
BuildItCommandLineArgs
BuildItCommandLineArgs类封装了编译连接工具支持的一组命令行参数。
注释
BuildItCommandLineArgs类，从System.Collections.Specialized域名空间的StringCollection类中派生出来，代表了BuildIt所支持的命令行参数集合。它被BuildInitializer用来判断一个命令行参数是否合法。
构造函数
|
BuildItCommandLineArgs |
初始化BuildItCommandLineArgs类的一个新实例 |
公共方法
|
ToString |
通过提供合法的命令行参数的字符串表示而覆盖System.Object::ToString()方法。 |
私有方法
|
None |
|
常见问题
我是否能够修改BuildIt的源代码？
是的，你可以修改并且扩展BuildIt的源代码。例如，您可以改变对Visual Source Safe的特定调用，并且建立一个Helper类，使它和您自己的源代码控制产品一起工作。请告诉我们您做了什么样的改变！请参阅下面的“反馈”部分与我们共享您的经验。
我是否需要在运行BuildIt之前安装Visual Studio？
是的，您需要在您将要使用BuildIt做编译连接工作的服务器或是工作站上安装Visual Studio——仅安装.NET Framework redistributable是不够的。
附录小结
这个附录叙述了BuildIt是如何按照简单和可扩展的想法进行构建的，这样您就可以针对特定的编译连接过程需求来使用BuildIt。请使用“反馈”部分提供的email地址来告诉我们您对于BuildIt的看法。
关于作者
Michael Monteiro是Sapient公司的一个技术咨询师和.NET微软认证专家，有着多于8年的专业经验。他目前工作在一个团队中，该团队负责为Sapient的技术团体提供结构化的指导。您可以通过mmonte@sapient.com与他取得联系。
关于Sapient
Sapient是一个顶级的企业和技术咨询机构，通过在一个固定价位的基础上提供对领先技术的快速应用和支持，来帮助全球2000个客户取得重大的商业成果。Sapient成立于1991年，目前有多于1500个雇员工作在位于亚特兰大、剑桥、芝加哥、达拉斯、杜塞尔多夫、伦敦、洛杉矶、米兰、慕尼黑、纽约、旧金山、多伦多和华盛顿的办公室中。关于Sapient的更多信息，请查阅http://www.sapient.com/。
合作者
对以下这些作出贡献和进行审查的人员致以深深的谢意：Bernard Chen（Sapient公司）、Brett Keown、Craig Skibo、David Lewis、Deyan Lazarov、Dimitris Georgakopoulos （Sapient公司）、Edward Jezierski、Filiberto Selvas Patiño、Jeff Pflum、Joe Hom (Avanade)、Ken Hardy、Kenny Jones、Korby Parnell、Martin Born、Mick Das、Mike Pietraszak、Niel Sutton、Oded Ye Shekel、Rajiv Sodhi （Sapient 公司）、Ray Escamilla、Rich Knox、Russell Christopher、Sumit Sharma（Sapient 公司）。
反馈
问题？评论？建议？如果您想针对BuildIt提出反馈意见，请使用e-mail地址：buildit@sapient.com。
如果您想与微软联系并提供反馈，请使用e-mail地址：devfdbck@microsoft.com。
合作者
对下列这些对本文档作出贡献和进行审查的人员致以深深的谢意：
Michael Day、Martyn Lovell、Brad Bartz、Izzy Gryko、Bill Hiebert、Jeff Pflum、Bernard Chen （Sapient）、 Michael Monteiro （Sapient）、Dimitris Georgakopoulos （Sapient）、Korby Parnell、Susan Warren、Chris Falter、Joel West、Dave Quick、Allan Hirt、Cathan Cook、Chong Lee、Milind Lele、Chris Brooks、Martin Petersen-Frey、J.D. Meier、Edward Jezierski、Jacquelyn Schmidt、Jeremy Bostron、Frank Hackländer （Siemens）、Reinhold Kienzle-Press （Siemens）、Sharon Bjeletich、Andrew Roubin （Voresite）。
其它资源
Patterns & practices是微软为结构设计师、软件开发人员和IT专家推荐的用于在微软平台上打造和管理企业系统的选择。Patterns & practices无论是对于IT基础架构还是开发主题都是可用的。
Patterns & practices基于实际经验帮助企业IT专家和开发人员迅速地打造解决方案，而绝非纸上谈兵。此技术指导得到了微软工程团队、顾问、产品支持服务和合作伙伴及消费者的审查和认可。全世界的机构将Patterns & practices用于：
削减工程花费
● 采用微软的工程成果，以节省项目的时间和金钱
● 听从微软的建议，以降低工程风险和取得可预测的成果
提高对解决方案的把握
● 在经过证实的微软建议的基础上构建解决方案，可获得对解决方案的整体把握，取得可预测的结果
● 提供经过PSS充分测试和支持的指导，不仅仅是例子，还有产品品质建议和代码
打造IT战略优势
● 得到关于解决当前的商业和IT问题的实用建议，同时使得公司能够全面利用未来的微软技术的优势
要想更多地了解patterns & practices，请访问：msdn.microsoft.com/practices
要想购买patterns & practices，请访问：shop.microsoft.com/practices
Patterns & practices对于IT基础架构和软件开发主题而言都是可用的。有四种类型的Patterns & practices可供利用：
引用结构
引用结构是IT系统级的结构，能够在普遍出现的场合中满足商业需求、操作需求和技术限制。引用结构主要是规划IT系统的结构，对于设计师而言是最为有用的。
引用构建模块
引用构建模块是可以重用的子系统设计，能够满足许多场合下的常见的技术改变需求。其中的许多包含了测试引用实现，以加速开发。
引用构建模块主要是关于如何设计和实现子系统，对于设计者和实现者而言是最为有用的。
可操作实例
可操作实例为在一个产品环境中配置和管理解决方案提供指导，是基于微软操作框架的。可操作的实例主要是关于关键任务和过程，对于产品支持人员最为有用。
范例
范例记录了已被证明的实例，允许将过去解决问题的经验重新用于当前的相似问题中。范例对于任何一个负责解决结构、设计、实现和操作问题的人而言是非常有用的。
要想更多地了解patterns & practices，请访问：msdn.microsoft.com/practices
要想购买patterns & practices，请访问：shop.microsoft.com/practices
2002年10月
引用结构
微软系统结构—企业数据中心2007页
微软系统结构—Internet数据中心397页
.NET的应用软件结构: 设计应用软件和服务127页
微软SQL Server 2000高可用性系列：卷1：规划92页
微软SQL Server 2000高可用性系列：卷2：配置128页
Exchange 2000 Server的企业通告引用结构224页
Content Management Server 2001和SharePoint Portal Server 2001的微软内容集成包 124页
UNIX 应用软件迁移指导694页
微软Active Directory分支办公室指导：卷1：规划88页
微软Active Directory 分支办公室系列卷2: 配置和操作195页
微软Exchange 2000 Server驻留系列卷1: 规划227页
微软Exchange 2000 Server驻留系列卷2: 配置135页
微软Exchange 2000 Serve升级系列卷1: 规划306页
微软Exchange 2000 Serve升级系列卷2: 配置166页
引用构建模块
.NET的数据访问应用软件模块279页
.NET的数据访问结构指导60页
设计数据层组件和跨层传递数据70页
.NET的例外管理应用软件模块307页
.NET的例外管理35页
.NET分布式应用软件设计中的监测 40页
微软.NET/COM迁移和互操作性 35页
.NET关联的应用软件的产品调试 176页
ASP.NET中的鉴证：.NET安全指导 58页
构建安全的ASP.NET应用软件：鉴证、授权和保护通信 608页
可操作实例
Exchange 2000 Server的安全操作 136页
微软Windows 2000 Server的安全操作 188页
微软Exchange 2000 Server操作指南 113页
微软SQL Server 2000操作指南 170页
配置.NET应用软件：生命周期指导 142页
使用Visual Studio .NET和Visual SourceSafe进行团队开发 74页
备份和恢复Internet数据中心 294页
要想找到当前列表中的文章，请访问：msdn.microsoft.com/practices
要想购买patterns & practices指导，请访问：shop.microsoft.com/practices