VS2008 Beta2的菜单与VS2005相比有了不少改进,最大的变化菜单功能与工作角色相关。

在Data下面是与数据专家相关的功能。比如：比较schema，比较数据，refactor，T-sql editor...

在Developer下是与开发相关的功能。比如测能测试，代码分析，code metrics..

下面两个是以前有的。

在Test下是与测试相关的功能。比如新建测试，测试列表，管理test Rig,测试配置等。

在Diagram下是与架构设计相关的功能。比如生成代码，添应用、endpoint、设置与约束等

SnagIt’s output for Team System lets you add screen captures to new or existing bugs with a single click. Stop trying to describe problems with tons of text – just show them. Plus, eliminate the hassle of attaching images!

How will I use this?

• Use images to give in-depth explanation of bugs or tasks.
• Save time by adding screen captures to existing work items.
• Use screen captures to illustrate design ideas.

see more:http://www.techsmith.com/snagit/accessories/teamsystem.asp

VS2005中的WebTest工具主对是针对于HTTP协议来做的，所以他不仅能测ASP.net的应用，还可以测任何基于http协议的应用，比如JSP、PHP等等。

WebTest在做数据源绑定时，只能很好地分拆Http的Get、Post请求数据包，这对测试webSite已经够了。但如果测web Service就相对不够用，因为WebTest不能分拆Soap包，没有对Soap包内数据进行绑定操作的界面，这一功能需要手工完成。下面就是一个使用VS2005 WebTest工具对webservice进行数据源绑定测试的例子。

1. 先准备一个WebService,并部署到IIS上。

这里有一个简单的WebService:

[WebMethod]

public int Add(int i,int j)

{

return i + j;

}

服务调用说明如下：

2. 准备测试数据

在数据库中准备了一个Test表，存放一些测试数据。

3. 新建Web测试

a) 新建测试项目

b) 新建Web测试

c) 当出现IE录制界面进，按Stop停止录制。

d) 在webtest1里添加Web service request

e) 在web service request里添加Header,其Name=SOAPActioin, Value=” http://tempuri.org/Add”，也就是服务协议里SOAPActioin的值。

f) 在web测试中添加数据源，指向test表。

g) 在http://localhost:8001/webservice/service.asmx?op=Add中注意SOAP请求中下列数据：

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<Add xmlns="http://tempuri.org/">

<i>int</i>

<j>int</j>

</Add>

</soap:Body>

将其中的i和j的值改为：{{数据源名.表名.列名}}，如下所示：

<i>{{MyComics1.tset.i}}</i>

<j>{{MyComics1.tset.j}}</j>

h) 将上面的信息加到Webservice request的stringbody中，如下图所示：

i) 将Web测试的URL改为所测的URL，如下图所示：

到此，测试设置完成。

4. 运行测试

a) 直接运行测试，结果正常。

b) 修改测试，让数据源中的每一条记录都做一次测试。

c) 结果如下图所示，每条数据都执过。

在VS2005里有源代码切换的设置，但在VS2003里没有。VS2003的源代管理器的配置依赖于注册表中的一条记录。
[HKEY_LOCAL_MACHINE\SOFTWARE\SourceCodeControlProvider]
"Microsoft Team Foundation Server MSSCCI Provider"="SOFTWARE\\Microsoft\\Team Foundation Server MSSCCI Provider"
"ProviderRegKey"="SOFTWARE\\Microsoft\\Team Foundation Server MSSCCI Provider"
[HKEY_LOCAL_MACHINE\SOFTWARE\SourceCodeControlProvider\InstalledSCCProviders]
"Microsoft Team Foundation Server MSSCCI Provider"="SOFTWARE\\Microsoft\\Team Foundation Server MSSCCI Provider"
"Microsoft Visual SourceSafe"="Software\\Microsoft\\SourceSafe"
当providerRegkey指到msscci时，就用TFS，指向VSS时就用的VSS。
网上有一个小工具SCPSelector.exe可以很方便地做providerRegkey切换，不用每次改注册表。每次切换过后要重启一下VS2003。

使用 RenameDT 更改 Team Foundation Server 数据层服务器名称,指命如下:

TFSAdminUtil   RenameDT  servername

Team Foundation Server 应用层需要知道数据层服务器的确切名称或地址，才能到达它。数据层名称和地址通过 Team Foundation Server 存储在应用层和数据层数据库的多个位置。当需要切换到新的数据层时，管理员必须确保 Team Foundation Server 指向新的数据层名称或地址。

TFSAdminUtil 命令行实用工具的 RenameDT 命令通过更新 Team Foundation Server 指向新的名称或地址，以实现数据层重命名过程的自动化。RenameDT 命令还可以通过脚本实现数据层重命名过程自动或定期进行。

RenameDT 命令只能运行于应用层上，因为它会在运行所在的计算机上搜索 web.config 文件。它既没有远程处理能力，也不会使用任何其他参数来指定目标应用层计算机。与ActivateAT一样,一个数据层只能对应一个活动的应用层，所以RenameDT指令还要修改数据库中的关于数据库的记录，很不幸的是，在TFS V1.0这里有一个bug，RenameDT不会改数据库中的记录，需要你手工改一下在ingetarted数据库中的tbl_database表中的数据。这个bug将在SP1中修复。

下面是TFS说明中的RenameDT使用情形

管理员可以在多种情形下使用 RenameDT 命令。下面列出了这些示例情形：

• 管理员需要在数据层上执行例程维护，使数据层脱机并将它替换为其他临时数据层以避免出现停机。
• 管理员运行 TFSAdminUtil 命令行实用工具的 RenameDT 命令，这样 Team Foundation Server 即可连接到新的临时数据层。完成维护时，管理员再次运行该实用工具以恢复使用以前的数据层。
• 数据层出现故障并且不起作用。
• 管理员运行 RenameDT 命令，将 Team Foundation Server 指向新的备份服务器。
• 正在将数据层升级到新的服务器。
• 管理员运行 RenameDT 命令，将 Team Foundation Server 指向新的数据层服务器。
• 新操作策略表明数据层必须遵循的特定计算机命名标准。
• 管理员使用 RenameDT 命令，将数据层重命名为更合适的名称。
• 组织或业务规模扩大，需要从单服务器解决方案迁移到双服务器解决方案。
• 新的独立数据层设置完毕后，管理员运行 RenameDT 命令，将 Team Foundation Server 指向新的服务器。

使用 ChangePassword 更改所有服务帐户的密码，指令如下：

TFSAdminUtil ChangePassword oldacct oldpwd newpwd [target]

参数说明

oldacct ：指定旧帐户名。

oldpwd ：指定旧密码。

newpwd ：指定新帐户密码。

target ：指定目标计算机。如果省略 target，则使用本地计算机。目标计算机必须为应用层服务器。

ChangePassword 命令由要更改服务帐户（例如，域\服务器名）密码的管理员使用。管理员更改域帐户上的密码，然后运行该工具，使用新密码更新所有的 Team Foundation 服务器。

ChangePassword 做了些什么呢？如果不用它怎样改服务帐户的密码？请往下看：

TFS运行时会用于两个服务账号，一个是TFSService运行账号（比如TfsService）、一个是报表服务器用来访问TFS数据账号(比如：TfsReports)。如果这两个账号的密码发生改变，须要对TFS服务进行重新配置，具体步骤如下：

1． 在IIS中修改下列应用程序池的运行账号TfsService的口令：

    a) TFS App Pool

    b) TFS Wss Pool

    c) TFS WssAdmin pool

2． 在windows服务中，修改下列服务的运行账号TfsService的口令：

    a) Code Coverage analysis Service

    b) Sharepoint Timer Service

    c) TFSServerScheduler Service

3． 在Reporting Service中修改下列数据源登陆账号TfsReports的口令：

    a) TFSOLAPResportDS

    b) TFSReportDS

重启机器或重启相应服务后，TFS就能正常工作了。

公司里的TFS的数据库出了一点问题，需将数据库恢复到之前的一个备份。恢复完了CheckIn本地的的更新，工作一切正常。但其它人从TFS上获得最新版本时却报文件的版本不对（比如某个sln文件），在本地workspace中用notepad打开发现，本来应当是一个XML文件，现在却成一个C#代码，而且是另一个team project的文件。随后所有人的机器上都有这个错，我的机子上也是。本以为是强制添加新文件造成数据库中File表中的content与Version表中的fullpath对应关系错误造成的，于是又一次恢复了数据库，本地好似一切正常，但在别人机器上错误又出现了。

一边先让项目给能正常工作，一边向GTSC写信，到下午时终于有了一些进展。TFS为了提高Versioncontrol Web service的性能，将已读出的文件在Web Server上进行了缓存，文件大多用zip进行压缩后放在Data目录中，下次有客户取最新版本就不用从Versioncontrol中读的了，而是从WebServer上直接读的。在TFS1.0里，一个数据库层只有一个应用层，正常情况下也相安无事。但如果直接对数据层进行操作，比如数据库恢复之类，那Web上的缓存与数据库中的就不一样了，所以就出现了文件名与文件内容不一致的情况。

删除Data目录下的所有文件夹后一切正常，可恶的缓存，让我白忙一天。

另有几件事，第一、删除缓存后最一次取最新版本，那个慢啊，本对缓存的一堆不满在慢慢等待中一点、一点、一点点地化解了，没他还真不行！第二、删之前我看一下Data目录，200M多，15000个文件，想能不能对他进行管理，查了一下资料，列在下面，希望对大家有所帮助。第三、如果你用了proxy，那proxy上的缓存也要一并删除。

Versioncontrol Web service中?Web.Config的设置如下：
fileCacheRoot：此设置是一个字符串，它描述作为版本控制服务器文件缓存根目录的目录路径。
CacheLimitPercent：此设置是一个数值，它表示可用于缓存的磁盘空间百分比。
CacheLimit：此设置是一个数值，它表示缓存的大小限制（以 MB 为单位）。
CacheDeletionPercent：此设置是一个数值，它表示达到缓存限制时将清空的缓存百分比。
LastWriteTimeUpdateWindow：此设置指示更新缓存中文件的 LastWriteTime 属性的时间间隔（以小时为单位）。此设置阻止对每个缓存命中请求的 LastWriteTime 更新，而仅在 LastWriteTimeUpdateWindow 中指定的持续时间到期后进行更新。此设置的默认值为 8 小时，设置范围为 1 到 24 小时之间。
StatisticsPersistTime：此元素指示应将统计信息写入磁盘的频率（以小时为单位）。默认值为 1 小时，设置范围为 1 到 24 小时之间。

本文适用场景：

    TFS服务器从一个域迁到别一个域中，这里包括服务器加入新域、服务运行账号改为新域的中账号，机器名称不改变。本文在TFS单机部署场景测试通过。

迁移步骤：

  1. 停止服务器上的TFS服务。

    a) 在IIS上停上TFS App Pool和Report Server Pool。

    b) 停止Reporting Service服务。

2. 将服务器加入新的域。

3. 修改服务账号。

    a) 检查新账号的权根是否足够。

    b) 将新账号设为以服务方式登陆。

    c) 修改TFS Service账号

        TfsAdminiUtil ChangeAccount OldAccount NewAccount Password

    d) 修改TFS Reports账号

        TfsAdminiUtil ChangeAccount OldAccount NewAccount Password

4. 修改Reporting Service的数据连接配置，将连接账号改为新域中的账号。

5. 在IIS上启动TFS App Pool和Report Server Pool，并进行测试

    a) TfsAdminiUtil status检查服务账号工作情况

    b) 使用VS2005进行测试。

方案配置：
  数据库服务器：TFSDB
  应用服务器：TFSAT_1（主要）,TFSAT_1(备用)
  DNS中一个A记录：TFSAT
在待机方案中主应用服务器坏了（关机、停止TFS服务），可以通过修改DNS指向将请求发给备用机器，从保证TFS的可用性。试验中在主、备两台服务器之间切换过多次，均能正常工作。
在切换过程中，服务端只要做两件事：
  1.DNS中TFSAT的IP指向备用机。
  2.在备用机上执行一个命令: TfsAdminUtil ActivateAT  TFSAT
客户端要做的就是一件事：
  1.执行命令：Ipconfig/flushDNS
  再次打开VS2005就好了，与平进正常打开VS2005一样。

热待机方案能做到的：
  a) 保证应用服务器的高可用性，应用服务器的可用性是整个TFS可用性最重要的因素，也是最容易失效的环节。使用热待机方案，主
应用服务器出现故障后，在几分钟之内能让TFS应用恢复正常工作。
  b) 热待机方案中用户干预少，对于TFS的客户端来说只是停了几分钟，不需要长时间等待，客户端也不用重新配置。
  c) 热待机方案中管理人员干预少，故障出现后，IT管理人员就可以进行修复，不需要TFS技术专家支援。
  d) 热待机方案中采用的双服务器安装方式，客户容量达到200用户，能保证今后一段时间MIS部门发展的需求。
热待机方案不能做到的：
  a) 热待机方案对数据库失效无能为力。
  b) 热待机方案对数据内容失效无能为力。
热待机方案中其它提高可用性措施：
  a) 数据服务器中使用磁盘阵列和备份文件异地存储来保证数据内容的高可用性。
  b) 一旦数据库服务器不能启用，可以快速装一台数据库服务器，恢复备份中的数据内容，从而使TFS正常工作。

在TFS双机热备的方案中，我们会用ActivateAt来做主应用服务器与备用服务器之间切换。那ActivateAt在这个过程中到底做了什么呢？

在TFS1.0版本里，一个应用服务器只能连一个数据库服务器，一个数据库服务器也只能连一个应用服务器。

在应用服务器的上的web.config文件有连接到数据服务器的连接字串，从而保证了应用服务器只会连到指定的数据库。如果要修改这个连接，可以使用RenameDT来完成。

那如果保证一个数据库只有一个应用服务器来连呢？一般来说数据库是只检查访问者的身份与权限，少有检查是哪个应用和机器发来的请求（应用程序角色除外）。TFS数据库连接也只检查来访者是否有权限访问数据，但在其数据中记录了合法访问的应用层的信息，这些信息分散在不同的表中，ActivateAt就是用来修改、同步这些信息的。

简单地说，ActivateAt做了四件事：

  1. 修改了TFSIntegration数据库中tbl_subcription表中的address列，将其改为新的应用服务器名称。

  2. 修改了TFSIntegration数据库中tbl_service_interface表，将以下属性绑定到新的应用服务器：

    a) WssAdminService

    b) BaseServerUrl

    c) BaseSiteUrl

    d) BaseSiteUnc

    e) ReportsService

    f) BaseReportUrl

    g) DataSourceServer

  3. 修改了TFSIntegration数据库中tbl_registration_extended_attributes表，将以下属性绑定到新的应用服务器：

    a) ATMachineName

    b) ATNetBIOSName

    在双服务器热待机方案中，ATMachineName总是指向A记录，但ATNetBIOSName却是指向正在使用应用服务器的机器名。所以，虽然备机也一直开着，服务也正常运行，但我们用VS2005去连接是总是报错。

  4. 重启IIS。

因为有ActivateAT这个工具，我们可以很方便地从一个应用服务器切到另一台备用的应用服务器，从而实现了TFS的高可用性。

在VS2005里有两个关于源代码的选项，对刚刚使用VSTS作源代码管理的开发员很有帮助。具体位置：Tools\Options，如下图所示。

1． Check in Everything When closing a solution or project.

在关闭项目时会提示你CheckIn项目中未CheckIn的项目。如果你不想CheckIn，比如就是要重启一下VS2005，按取消就可以了。当项目文件比较多时（通常都是这样），能避免我们忘记CheckIn。

2． Editing : Prompt for Check out

有时，在一个文件上不小心按了一个回车，代码已经CheckOut了，这样的文件很容易忘记CheckIn。现在有一个选项，当你对文件内容有修改时，提示你CheckOut，这样就能区分是真要CheckOut，还是一个误操作，比如一个不经意的回车。

1. VSTS的失效类型

(1) TFS数据库内容失效:数据被错误删除
(2) TFS数据库服务失效:数据服务不能启用
(3) TFS应用层服务失效:应用层服务不能启用
(4) TFS客户端失效（本文不考虑）
(5) 网络失效（本文不考虑）

2. VSTS高可用性方案
(1)无备机的备份方案
(2) 有备机的备份方案
(3) 热待机系统
(4) 热待机系统+数据库群集

3. 无备机的备份方案

基于数据库的备份与恢复技术。
如果数据损坏，通过恢复到上一次备份点上，保证VSTS的可用性。恢复时间： 30分钟。
如果数据库服务或应用层服务失效，则重装TFS，并恢复数据库。恢复时间：一天。
成本：一台TFS服务器，一台可共享文件的服务器。

4. 有备机的备份方案

基于数据库的备份与恢复技术。
如果数据损坏，通过恢复到上一次备份点上，保证VSTS的可用性。恢复时间： 30分钟。
如果数据库服务或应用层服务失效，将数据库恢复同名的备机上。恢复时间：2小时。
成本：两台TFS服务器，一台可共享文件的服务器。

5. 热待机系统

两台在线的TFS应用服务器，一台主服务器，一台备用服务器，此方案能保证应用层的主可用性。
如果数据损坏，通过恢复到上一次备份点上，保证VSTS的可用性。恢复时间：30分钟。
如果应用层服务失效，启用另一台备用的应用服务器。恢复时间：10分钟。
如果数据库服务失效，刚要重装数据库服务器，并进行数据恢复，恢复时间：2小时。
成本：两台TFS应用服务器，一台TFS数据服务器，一台可共享文件的服务器，管理成本。

6. 热待机系统+数据库群集

此方案在热待机系统基础之上加上数据库群集，提高数据库的可用性，和恢复速度。
如果数据损坏，通过恢复到上一次备份点上，保证VSTS的可用性。恢复时间：30分钟。
如果主应用层服务失效，启用另一台备用的应用服务器。恢复时间：10分钟之内。
如果主数据库服务失效，自动切到备用数据库服务器上，恢复时间：1分钟之内。
成本：两台TFS应用服务器，两台TFS数据服务器，一台可共享文件的服务器，管理成本。

如果在安装TFS之前，有安装过TFS或本机装有VS2005具连接过其它TFS，在安装时可以出现有8100错误：TFS setup error: 28100 Error Loading Event web Service.

解决方法：在注册表中删除：HK_Current_User/software/microsoft/visualstudio/8.0/Teamfoundation/servers.
这里存放的是已连接TFS的记录。

在TFS里，我们有两种途径来做代码行的统计工作。

1．其于TFS的代码搅动模型，我们可以方便地查看出每一次签入时代码变更的信息，比如，新增行数、修改行数、删除行数等。通过统计，我们可以将这些信息根据项目、员工、时间进行汇总。由于这种统计是基于变化集的，所以他能客观反映过程的工作量，比如我们可以汇总一个员工在一段时间内新增行数、修改行数、删除行数。实现方式：

   a) 在VS2005中新建一个报表项目，

   b)选择分析服务是的TFSwarehouse，选择code churn项目

   c)在报表主体中选需要测量值及分类

   d)按需要在表头添加参数。

2． 基线的比较，这个主要用于评估项目的规模，比如比较Beta1与Beta2间的变化。由于TFS的代码搅动是基于变化集的相对变化，所以不适合两个基线之间的绝对比较。通过TFS API的研究，我们可以用以下的方式来实现：

   a) 前提条件，在TFS，有多个标签来标识不同的基线。

   b)程序连到TFS，选择某个团队项目的两个不同标签（基线），根据标签枚举每个基线中的文件，比较每一对文件的内容，从而获得是不同、相同、新增、删除。

   c)对于不同的文件对，使用difference.Difffiles来标识内容的变化，哪行是新增，哪行是修改，哪行是删除，并统计他们的数量。对于删除和新增的文件，统计文件中的行数。

   d)根据以上数据，生成报表，列举：源文件、目标文件、Action、新增行数、修改行数、删除行数。

   e) 在报表的尾部可以做一个汇部，说明两个基线间的差别。

问题描述：
10月29，30两天，将ECTFS01作了迁移，10月31日早上检查团队项目门户时发现剩余工作报表不正常，10月31日这一天的剩余工作项为零。如下图所示：

问题排查：
   1. 检查其它报表，与时间相关的报表，在10月31日全指示为零。
   2.怀疑TFSWarehouse没有及时填空数据，在分析服务里，选中“TFSWarehouse”进行Process。这个动作在迁移后也做过，当时一切正常。但这次做下来报很多错：部分列举如下：
      a)OLAP 存储引擎中存在错误: 找不到以下属性键: 表: Code_x0020_Churn，列: Changeset，值: 2038。
      b)OLAP 存储引擎中存在错误: 由于找不到属性键，导致其被转换为未知成员。属性 Changeset 所属维度 Changeset 源自: 数据库: tfswarehouse，多维数据集: Team System，度量值组: Code Churn，分区: Code Churn，记录: 17708。 
      c)OLAP 存储引擎中存在错误: 由于处理过程中遇到的错误数达到为操作定义的最大允许错误数，处理操作结束。 
      d)OLAP 存储引擎中存在错误: 处理“Code Churn”分区时出错，该分区属于 tfswarehouse 数据库的“Team System”多维数据集的“Code Churn”度量值组。
      e)OLAP 存储引擎中存在错误: 由于处理过程中遇到的错误数达到为操作定义的最大允许错误数，处理操作结束。
      f)OLAP 存储引擎中存在错误: 找不到以下属性键: 表: Current_x0020_Work_x0020_Item，列: Area，值: 14。
      g)OLAP 存储引擎中存在错误: 由于找不到属性键，导致其被转换为未知成员。属性 Area 所属维度 Area 源自: 数据库: tfswarehouse，多维数据集: Team System，度量值组: Current Work Item，分区: Current Work Item，记录: 301。
      还有一个错说没有2006-10-31这项出现多次。如下图所示：

 
   3.在错误记录里还有的时间描述是[2006年10年]，本以为是中文版的客户报的错误信息，转用英文版SQL管理器，也一样报[2006年10年]信息，进而怀疑服务器上的时间格式不匹配。
   4.检查TFSWarehouse中的 Date各Today维度，发现日期格式不一致，today中的是中文格式。对today和Date进行填充也出错。
   5.到SQL中的TFSwarehouse数据库检查today中的数据是中文的，用另一台服务器的数据覆盖后，一切正常，多维数据集能填充，报表也能显示，但日期不是今天。
   6.通过对SQL的监视，发现是TFSwarehouse对today表进行操作的，根据进程号找到相应的进程和进行的运行者。
   7.修改运行者的文化属性，将日期改为英文格式，重启进程后，一切正常。如下图所示：

结论：
由于TFS服务的运行者的日期格式与数据库中的不同，造成了在生成多维数据集时，时间不能匹配，因而报表出错。