我正在尝试使用 MSBuild 和 TFS。
我已经成功创建了自己的 MSBuild 脚本，该脚本在命令行中运行得很好。该脚本适用于 csproj 文件，并编译、混淆、签名和复制所需的所有内容。
但是，查看 TFS 和 Team Build 的文档，它似乎期望解决方案作为脚本的“输入”。
此外，我还没有找到一种简单/直观的方法来从 TFS 执行“获取最新版本”作为脚本的一部分。我假设团队构建会自动对其要编译的解决方案执行“获取最新”操作，但同样 - 我不(想)使用解决方案...
有什么见解吗？有什么指示吗？有链接吗？
最佳答案
团队 build 定义了关于 25 targets of its own 。当您对 Team Build 进行排队时，它们会按照 @ MSDN 列出的预定义顺序自动为您运行。不要修改这个过程。相反，只需设置 couple of these properties决定任务的行为方式。例如，设置 <IncrementalGet > 如果您想要普通的 Get 行为，则为“true”，如果您想要更接近tf get/force的行为，则为“false”。
就运行您自己的 MSBuild 脚本而言，这并不是必需的。从为您提供的 TFSBuild.proj 文件开始。它应该只需要最少的修改即可完成您所描述的所有操作。通过覆盖 AfterCompile 或 AfterTest 等任务来调用您的混淆和签名代码。将自动部署代码放入 AfterDropBuild 中。等等
如果您进行适当的重构，即使是非常复杂的场景也是可能的。查看过去的答案 #1 #2 .
就实际编译而言，Team Build 在解决方案上运行是正确的。我建议给它想要的东西。我将是第一个承认 *.sln 文件很丑陋并且基本上没有文档记录的人，但至少您将工作转移到经过良好测试和支持的产品。
如果您确实愿意，您可以给它一个空白/虚拟解决方案，并使用您的自定义编译器逻辑覆盖 CoreCompile 任务。但这实在是自找麻烦。至少，您会失去 Team Build 在构建多个平台和风格时的所有灵活性。更实际的是，您必然会花费大量时间来调试一些旨在“正常工作”的东西，而且目前还没有好的 MSBuild 调试器(据我所知)。在我看来，不值得。
顺便说一句，解决方案文件不会影响 Get 过程。正如您在第一个链接中所看到的，获取很早就完成了，远早于 Team Build 读取解决方案文件。除了像<IncrementalGet这样的几个选项>，这根本不受 MSBuild 控制 - 特别是，要下载的路径由与构建定义关联的工作区映射确定。即，它们存储在 Team Build SQL 数据库中，而不是文件系统中，并使用调用 TFS Web 服务 API 的工具(如 Team Explorer)进行管理。
关于tfs - 使用 MSBuild 和 TFS，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1165293/