构建vNext任务是对先前构建过程的一个很棒的改进。但一个缺点是我无法使某些任务成为条件。我可以为每个组合创建一个额外的构建，但如果我们必须更改构建的其他部分，这会明显地扩展并导致大量额外的工作。
相反，我更愿意编写自己的PowerShell任务，可以调用现有的构建任务。至少有一个缺点（如果没有构建专门针对vso任务，构建代理将不会下载它），但考虑到我们正在使用内部部署TFS和构建代理，我可以忍受这个。
我尝试做类似以下的事情：
$path = get-item "$env:AGENT_HOMEDIRECTORY\Tasks\NuGetPackager\0.1.56\NuGetPackager.ps1"
& "$path" -searchPattern $searchPattern -outputDir "$packageFolder" -configurationToPackage $configurationToPackage -nugetAdditionalArgs "$nugetAdditionalArgs -version $nugetVersion"
遗憾的是，这会导致以下错误：
2016-04-12T09:50:22.3652811Z ##[error]import-module : Could not load file or assembly 'Microsoft.TeamFoundation.DistributedTask.Agent.Interfaces,
2016-04-12T09:50:22.3652811Z ##[error]Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find
2016-04-12T09:50:22.3652811Z ##[error]the file specified.
2016-04-12T09:50:22.3652811Z ##[error]At C:\Agent1\Tasks\NuGetPackager\0.1.56\NuGetPackager.ps1:19 char:1
现在我在网上找到的一个解决方案表明我可以向GAC添加查找dll，但我真的，真的不想这样做。很明显，当从TFS直接调用时，任务工作正常，所以我缺少什么配置？
我尝试将包含dll的文件夹添加到路径中，甚至在PowerShell中显式调用SetDllDirectory，但这些都没有帮助。
环境：构建代理和TFS服务器上的Windows Server 2012 R2。 TFS 2015 Update 1.。
答案 0 :(得分：3)
构建代理程序用于2015 RTM直到更新2的Powershell任务主机是一个自定义主机，它可以执行创造性的事情来解析程序集和处理输入/输出。无法从代理外部调用这些任务。
另外，使用Node实现了很多构建任务，因此您必须检测哪个是哪个并相应地调用它们。
构建任务是migrated to a new vsts-task-lib，它将支持代理外调用。这些将允许你想要的。
同时您可以执行现有任务（在大多数情况下，它们是一个简单的清单加脚本），并在您粘贴变量的任务中添加一个string参数，然后您可以作为条件对待。您需要更换所有标准任务。然后再推它们。如果您保持ExtensionID和任务GUID相同，它们将作为就地替换。这可能是最简单的方法来做你想要的，而不必执行任何带走任务的UI的黑客攻击。只需将版本号设置为高得离谱的值，例如100.0.1.83。这样你总会最终使用你的版本。
注意：新构建是可重复的，因为多次调用相同的构建它们总是产生相同的结果。可以在存储在源代码管理中的自定义PowerShell脚本中捕获条件操作。这些可以作为工作流程的一部分执行。