目前我正在将TFS 2012更新到2013年。我的计划是使用默认的构建过程模板，如果可能的话，坚持使用它。现有的构建定义使用旧的TFS方法和TFSBuild.proj文件。在这些项目中，一切都在发生。初始化解决方案目录，构建，清理，运行单元测试，删除文件等。与2013构建流程模板相比，这是不正确的，因为工作流程具有构建，清理，运行测试，删除文件等活动。似乎TFSBuild.proj文件中使用的目标文件是以前的TFS版本，并且尚未更新到2013版本。
问题是除了构建，清理，运行测试drop文件活动之外还需要其他活动。在某些文件中更改版本号，对dll进行模糊处理，如果源不包含任何不需要的文件则检查过程，压缩pdb文件等等。
当然，可以使用PowerShell脚本执行这些任务/活动。另一方面，处理项目文件中的任务似乎也是合乎逻辑的。我对在项目文件中执行额外任务的担心是，在调用MSBuild活动之后，TFS正在运行测试，删除文件等活动。
有人能指出我正确的方向吗？我是否需要可以在构建过程模板中使用的自定义开发的活动？或者正在使用PowerShell脚本最佳实践？
答案 0 :(得分：4)
我想你已回答了自己的问题！ Poweshell是前进的方向！
我想说修改XAML和编写自定义活动应该只考虑powershell不适合你，或者你的脚本变得如此庞大和难以调试，将它们转换为代码是有意义的。正如您所提到的，在MSbuild活动完成后，其中一些任务需要很好地执行，这样就无法正常工作。
看起来你想在进程中的定义点做一些相当简单的步骤，而powershell扩展点对此非常适合。
在预构建步骤中进行版本控制的简单脚本。检查不需要的文件的来源也可能在这里发生。
混淆，压缩和复制的东西可能会在测试后发生。
从可维护性的角度来看，我会说PowerShell拥有比Windows Workflow和MSBuild更大的用户群，因此这种方法的另一个优势。