我正在更新我的XAML构建工作流程以及随之而来的自定义程序集。我在带有测试构建代理的计算机上有一个测试构建控制器。
我还想在我的实时构建机器上部署这个控制器的测试代理（硬件速度要快得多）。
在Visual Studio中，如果我转到“管理构建控制器”对话框，我可以通过为其提供新版本自定义程序集的路径来配置我的测试控制器。
我的测试控制器和实时控制器具有不同版本的自定义组件。
我认为构建代理运行的构建服务是一个进程，所以我不确定一个进程是否可以加载两个不同版本的自定义程序集（因为此自定义程序集的实时和测试版本具有相同的名称）。
我可以像这样混合搭配......在一台机器上建立代理程序，这些代理程序注册了不同的控制器，这些控制器本身有不同版本的自定义程序集吗？
更新
我找到了这个页面......
...它的图表似乎在一台机器上显示了两个代理，这些代理注册了不同的控制器。我仍然不确定它是如何工作的，因为我不确定单个服务是否可以加载两个不同版本的自定义程序集。
更新2
也许Application Domains允许这个工作？
https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx
答案 0 :(得分：1)
一个构建代理只能有一个构建控件。但是，一个构建控件可以在不同的物理机器上拥有多个构建代理。
正如此blog解释构建服务是一个Windows服务，只有一个构建控制器，仅为一个团队项目集合配置并具有多个根据需要构建代理。因此，如果构建代理可以由两个不同的构建控件控制，它可能同时具有两个不同的构建服务，这是不可能的。
因此，博客中的图表显示了在一台计算机上注册了不同控制器的两个代理程序。这两个代理用于两个不同的项目集合。
如果要分发负载，只需在不同的计算机上安装多个构建代理即可。您可以参考Why and when to have multiple build agents?
的详细信息另一种方法是使用TFS 2015和Visual Studio Team Services中引入的新构建系统 - vNext 。它是基于代理的。没有控制器，您可以在一台计算机上安装多个代理。
代理在池中分组并在服务器级别上运行，甚至允许您跨集合使用它们。