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