利用这个对象来递归地访问项目中的所有源代码文件。在这里我用一个叫getVssHistory的递归方法来实现访问所有项目源代码文件在指定的日期范围内的版本历史：
public void getVssHistory(ref StringBuilder result,IVSSItem vssFolder,DateTime from,DateTime to)
{
IVSSItems items = vssFolder.get_Items(true);
foreach (IVSSItem item in items)
{
//判断是文件还是目录
if (item.Type != 0)
{
IVSSVersions versions = item.get_Versions(1);
foreach (IVSSVersion version in versions)
{
//如果是在指定时间范围内的版本，则纳入返回结果
if ((version.Date > from) && (version.Date < to))
{
result.AppendLine(item.Spec + " ( version "
+ version.VersionNumber.ToString() + " ):"
+ version.Date + " , " + version.Action
+ " by " + version.Username + "\n");
}
}
}
else
{
//如果是目录，还需要递归下去
getVssHistory(ref result,item, from, to);
}
}
}
可以充分利用IVSS的对象模型，获取更多你需要的信息。例如所有当前处于签出状态的文件，某个VSS用户的权限，等等。
把小程序纳入每日构建的执行框架中，或者就简单地利用Windows的任务计划每天晚上定时执行，获取当天的VSS配置库的更改信息，或者其它需要的信息，在第二天早上把这份小小的报告放在每个人的邮件中，每个人都能从这些报告中获得需要的信息。
程序的使用
完整的程序源代码可以到我的搏客下载 http://www.51testing.com/?141783/action_viewspace_itemid_64835.html
其实这样一个程序对于开发人员也是非常有用的，我们经常发现自己的bug修改好了，但是过几天又被reopen了，原因是改好的程序又被某个鲁莽的家伙覆盖了。如果每天都能知道其他人在昨天做了什么更改，尤其是清楚是否对自己的“敏感地带”动了手脚的话，很多源代码控制的问题也就能及早发现并修正了。
但是更重要的是要把这些记录作为沟通的信息。作为配置管理员，即使是在不规范的配置管理流程中，也需要做好配置库的更改记录和审计工作，当发现某些文件的更改非常频繁，或多人频繁交替更改同一个文件时应该主动问个究竟；当测试人员发现昨天存在源代码的更改时，应该主动联系更改的开发人员，具体了解更改的内容，更改涉及的范围是什么，是否需要及时进行测试，对自动化测试脚本是否有影响，等等。
流程的改进是一个循序渐进的过程，如果改进比较缓慢，或者停滞不前，不要等待某个人来搭救我们，自己先想想，有什么东西可以做的，不要依赖流程，更不要互相埋怨，毕竟流程是为了帮助我们建立正确的做事方式，减低出错的机会，而要想做对事情，前提是建立起正确的思维。
- 数据库跨平台迁移方法浅析
- C#连接数据库和更新数据库
- 细说如何迁移Analysis Services数据库