使用TFS 2015，我们制作了一个vNext(VSTS)任务，该任务将查找选定的文件，替换一个令牌(版本号是它开始的地方)，写出对文件的更改，并签入该文件，并对更改的性质发表评论。它在构建过程中通过自动化实现了这一点。
我们即将升级到DevOps 2020，2015年的TFS管理工具已被弃用，这本身就很好，但我们仍需要在构建过程中自动化这些文件更改，包括注意更改性质的签入。
那项老任务失败得很惨，直接改头换面。我已经将这个过程重新编写为C#控制台应用程序项目，并计划在PowerShell脚本中调用它，但我在这个计划中遇到了一些障碍。
到目前为止我所做的一切。
-
我为VSTS任务编写了一个task.json，它接受传递给PowerShell脚本的参数。
-
我已经编写了一个PowerShell脚本，该脚本调用C#控制台应用程序来定位和更改任务指定的文件中的令牌。更改文件内容后，它将覆盖原始文件。
我似乎有两个问题，到目前为止，我还无法解决。
- 我希望(如果任务参数指定)将C#代码中的管道环境变量$env:BUILD_BUILDNUMBER更改为一个新值。我使用下面的C#命令，使用第三个参数，希望这将允许管道看到它对变量所做的更改：Environment.SetEnvironmentVariable("BUILD_BUILDNUMBER"，BUILDNUMBER，EnvironmentVariableTarget.Machine)；(我也尝试过不使用参数，也尝试过User和Process，但都没有成功。)该变量不会"设置"为管道在控制台应用程序之外查看
- 我需要检查步骤2中所做的更改，从C#代码返回到代码库，并附上一条简短的注释。管道最初的"Get"调用tf，但我没有取得同样的成功。我发现，如果我在构建机器上调用tf.exe的VS2019副本或"externals"中的代理副本，无论是从C#还是从后来的PowerShell脚本，我都会得到"##[error]无法确定工作区。您可以通过运行"tf workspaces/collection:TeamProjectCollectionUrl"来更正此问题；不用说，稍后关于运行tf工作区的说明没有帮助
我希望这些事情有简单的解决方案。我已经搜索过，但没有找到对DevOps 2020的API调用，该调用将检查代码。也许这并不存在。至于环境变量，我有点神秘，为什么EnvironmentVariableTarget.Machine不工作。我怀疑这与没有调用##vso[]方法有关，但我不确定如何将我的发现从控制台应用程序(如果成功，还需要返回0，否则失败)传递到可以更容易地更改变量的PowerShell脚本。
如果对此有什么好的想法，我真的很感激你能提供的见解。我已经做了一段时间了，我不确定还需要考虑什么才能使这项工作成功。
使用TFVC而不是Git，以及许多其他小的遗留技术项目，使使用新工具变得有点难以理解，就像在这种情况下一样。
因此，我的第一个问题是，在构建开始前更新构建任务中的环境内部版本号。我能够从C#代码中设置变量，方法是打开一个PowerShell进程，该进程使用PowerShell中的##vso[Build.UpdateBuildNumber]函数更新变量。执行此操作的C#代码如下所示：
var ps = @$"C:WindowsSystem32WindowsPowerShellv1.0PowerShell.exe";
var script = $@"SetEnvironmentBuildNumber.ps1";
if (File.Exists( script )){
if ( File.Exists( ps ) )
{
await Task.Run( () =>
{
var scriptWithArguments = string.Concat( Path.Combine( Directory.GetCurrentDirectory(), script ), " -newBuildNumber ", newBuildNumber);
Process.Start( ps, scriptWithArguments );
} );
}
else
{
Console.WriteLine( $"PowerShell File Not found at: {ps}" );
}
}
else
{
Console.WriteLine( $"The current directory is: {Directory.GetCurrentDirectory()}");
Console.WriteLine($"Script File Not found at: {script}");
}
SetEnvronemntBuildNumber.ps1中的PowerShell脚本如下所示：
[CmdletBinding()]
param(
[string][Parameter(Mandatory=$true)]$newBuildNumber
)
Write-Host( "Setting the new build number - " + $newBuildNumber )
Write-Host( "##vso[Build.UpdateBuildNumber]$newBuildNumber" )
事实证明，这个练习帮助我理解了Undetermined Workspace，我的问题#2。
如果您查看我的C#代码中的If语句，您会注意到一个检查，看看当前工作目录是什么目录。发现我的新任务将当前工作目录更改为我的任务所在的位置，而不是管道的工作目录，我有理由暂停。
尽管如此，我还是退出了C#代码，回到了我的PowerShell脚本中，我不是在看解决方案的目录，而是在看Task目录。如果我从这个视图调用tf，就没有源代码，因此没有办法确定WorkSpace。
解决方案很简单，可以说，有一个管道系统环境变量可以让我回家。调用PS Set Location如下，就在我调用tf vc checkin之前。。。允许tf找到工作区并保存我的更改。
Set-Location $env:System_DefaultWorkingDirectory
这就是它所需要的，所有这些调整都是无辜的，但在没有任何正式的DevOps管道培训的情况下诊断起来非常麻烦。当我们试图弄清楚如何从TFVC获得Git时，我期待着DevOps带来更多的"乐趣"。。。我相信并不是我们所有的遗产都会发生如此重大的变化。
谢谢你的建议，我希望这能帮助其他陷入遗产世界并试图走出困境的可怜灵魂。