我正在尝试升级现有的放置，并且需要在将放置文件夹部署到目标环境之前验证给定的内部版本名称/编号是否有效（状态和质量）。
基于这样的博客（http://www.woodwardweb.com/dotnet/tfs_build_api_b.html），我试图像这样连接到我的构建服务器，但没有成功：
string tfsProjectCollectionUrl = @"http://collectionServer:8080/tfs/collection";
var tfs = TeamFoundationServerFactory.GetServer(tfsProjectCollectionUrl);
tfs.EnsureAuthenticated();
IBuildServer tfsBuildServer = tfs.GetService<IBuildServer>();
//tfsBuildServer == null
我有两个服务器，集合和构建。 Build上的TFS管理控制台显示“为collectionServer \ collection配置的构建服务”。不知道我在这里想念的是什么。
更新：
我利用了MSDN支持资源，因为这在时间上很关键，并且通过将这些操作提取到外部程序集而取得了一些进展。我获取集合的方法看起来不错，只是对在CodeActivity内部生活感到不高兴。现在，CodeActivity调用此外部程序集，并向我返回我的dropPathToPromote，或者如果不满足状态和质量条件，则引发异常。
这在测试工具工作流程中工作正常，但不在飞行中。我在执行构建的前6-7秒内收到此错误：
Could not load file or assembly 'MyTFSAPICallingAssembly.dll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.新程序集包含在我的“自定义程序集” VCS文件夹中，供构建控制器使用，代理临时文件夹已使用这些dll更新（所有外部程序集和我的自定义程序集），新的“构建定义”呈现了包含此CodeActivity的过程模板毫无例外，其他引用我的根自定义程序集的Build Definitions都可以正常执行。
最佳答案
好吧，我感觉像个菜鸟。我在其中放置TFS API代码的程序集上的平台被标记为“ x86”，而调用CodeActivity程序集的平台被标记为“任何CPU”。一旦修复，构建就可以执行了。我仍然有一些辅助构建失败需要清理，但看来我的问题已解决。