我将此分为两个问题，但解决其中任何一个都会解决另一个问题。
问题1： 当我使用下图中底部的部分并添加＆＃34;配置以发布＆＃34;时，构建不会触发发布管理。
我查询构建日志几个小时，发现当它发现配置＆＃34;与当前＆＃34;
不匹配时它会停止发布如果ConfigurationsToRelease匹配当前 初始属性值 条件= 错误 最终财产价值 条件= 错误 最终财产价值 条件=真
在更多的话之前，我将展示一张总结起来的图片： the build definition and ms build logs在默认情况下，要发布的配置为空，发布管理将从此时开始并写入日志＆＃34;发布构建＆＃34; （作为发生的命令），构建将触发发布管理。
如果你看一下我的tfs构建配置，你可以看到它与高级常规ms构建配置完全相同，但我仍然得到这个不匹配的错误。 在任何情况下，我只有一个对话框来填充构建定义中的配置，如“配置对话框”中所示。在上面的图片中。
前几天，我成功地通过添加发布配置在同一个项目中以这种方式发布了一次或两次，它以某种方式工作，但后来停止工作（工作一次或两次作为一个小故障我觉得有些东西被缓存在那里）但99其他尝试失败的百分比，自从我几个月前第一次尝试它以来，总是停止从tfs到释放的触发器。 这里有人经历过吗？我看了很多地方，发现只有一个人抱怨它。他的解决方案是删除它（不完全是一个解决方案） 是否有可以解决此问题的构建参数？ （/ P：东西=东西）
问题2：如果有人能以不同于rm配置的方式解决问题，那么我就不需要解决问题1.
对于任何有兴趣的人，为什么我甚至搞乱了构建定义的发布配置部分，因为我希望rm 等待以便在rm干预之前发生所有转换，这个似乎是一种告诉rm的方式，好伙计，看到那里？你有2个配置等待他们的构建。
事情是，默认情况下，当配置部分为空时，rm会妨碍tfs构建，而tfs构建会受到rm的影响，就像循环等待一样。当tfs build等待rm完成它在第一次构建之后运行时，rm期望两个转换的文件夹都存在于构建输出中，tfs想要继续构建第二个配置（和转换）但是rm已经参与，寻求它是第二个配置，在找不到它时打破了构建，因此永远不会创建第二个配置，而rm仍在等待它，而tfs build等待rm和构建中断。混乱？请再次阅读并查看下面的图片，因为它非常有趣。
清晰度的更多信息： RM的下一阶段是在它已经存在之前尝试从构建输出文件夹中获取内容。 例如，如果我将Release build设置为true，它将只构建第一个配置（创建一个文件夹，下面的图片），rm将在第一步成功（QA.Release），并继续strait尝试获取Release for its下一阶段，但它尚未由TFS Build构建，它等待rm完成它在tfs构建工作中的奇怪干预。就像我上面说过的那样，我确信我已经看过它在我尝试过的一个版本中工作过一次或两次。
答案 0 :(得分：2)
如果我理解您的情况，我认为您的问题是您正在构建多个配置。这打破了持续交付的核心原则之一，即对于给定的版本，您应该只构建一次，并按顺序将相同的构建部署到管道中的每个阶段。
为了做到这一点，你的构建需要与阶段无关，这在实践中意味着所有配置（例如数据库连接字符串）都需要被标记化，以便可以为特定阶段交换正确的值（QA，Release等等）。我有一个博客文章系列here，它详细解释了整个过程（对于示例Web应用程序）。
答案 1 :(得分：0)
我设法解决问题2，并且通过这样做，问题1不再相关。 我切换到ReleaseTfvcTemplate.12.xaml作为构建模板（可在C：\ Program Files（x86）\ Microsoft Visual Studio 12.0 \ Release Management \ Client \ bin中找到）
然后构建在RM介入之前完成所有配置。
真的看起来像是ReleaseDefaultTemplate.11.1.xaml中的一个错误，或者这可能是因为我使用了一些额外的msbuild参数（需要它们），或者我正在使用慢速猎豹在Windows服务上创建转换（转换仅在Web应用程序中引入。）
无论哪种方式，我现在都能够执行高级任务，例如使用转换来添加生产中应该不同的\ remove标签，例如，我可以在配置文件中使用诊断来进行qa使用，然后将其移除以进行生产，以使详细程度降低。我仍然将RM PlaceHolders 技术与转换技术结合使用，享受与环境相关的变化这两个世界，但仍然通过在所有环境中传递相同的构建（dll）来保持原则。 / p>
