问题描述
大约一年前有人提出并回答了类似的问题，但要么是不同的问题(一切都处于测试阶段)要么被误诊.它位于此处:MSbuild 任务失败，因为任何 CPU"解决方案是乱序构建的.
A similar question was asked and answered about a year ago, but was either a different issue (everything was in beta) or misdiagnosed. It's located here: MSbuild task fails because "Any CPU" solution is built out of order.
我的问题是我有一个wix安装程序项目，周一升级到Tfs2010后，构建链接失败，因为在项目中找不到Wpf应用程序的构建产品.经过一番挖掘，那是因为它还没有建成.在 Vs2010 中构建正常工作.wix项目设置为依赖Wpf项目，在IDE中查看Project Build Order时，一切正常.
My issue is that I have a wix installer project, and after upgrading to Tfs2010 on monday, the build fails on linking because it can't find the build product of the Wpf application in the project. After some digging, it's because it hasn't been built yet. Building in Vs2010 works as normal. The wix project is set to depend on the Wpf project, and when viewing Project Build Order in the IDE, everything looks as normal.
问题最初是在解决方案中只有两个平台定义时遇到的；x86 和 x64.还有两种风格，Debug 和 Release，TFSBuild.proj 设置为构建所有四种组合.任何地方都没有出现 AnyCPU.根据上面引用的问题，我尝试将 Wpf 项目更改为使用 AnyCPU，以便首先构建它.此时，wix 项目使用了确切的配置，而 Wpf 项目使用了带有 AnyCPU 的风味.然而，这样做似乎并没有改变任何事情.
The problem was originally encountered with only two platform definitions in the solution; x86 and x64. There are also two flavors, Debug and Release, and TFSBuild.proj is set to build all four combinations. There was no occurence of AnyCPU anywhere. Per the referenced question above, I tried changing the Wpf project to use AnyCPU so that it would be built first. At this point, the wix project used the exact configuration and the Wpf project used the flavor with AnyCPU. However, doing so didn't seem to change anything.
我使用的是 Tfs2010 RTM、Vs2010 RTM 和最新版本的 Wix，在撰写本文时为 2010 年 4 月 2 日的 3.5.1602.0.还有其他人遇到这种情况吗?
I'm using the Tfs2010 RTM, Vs2010 RTM, and the most recent version of Wix, which at the time of this writing is 3.5.1602.0, from 2010-04-02. Anyone else running into this?
2010-04-27:经过大量挖掘并在克隆的 VM 构建机器上进行复制后，我相信我知道发生了什么以及发生了什么故障，但我不太清楚知道如何修复它.
2010-04-27: After a fair amount of digging, and reproducing on a cloned VM build machine, I believe I know what's going on and also what's failing, but I don't quite know how to fix it.
情况是这个错误似乎表现出基于解决方案文件中纯粹的运气项目排序的症状.解决方案文件似乎只是按照项目出现的顺序盲目地构建项目，依靠其检测未构建的引用并在需要时按需构建它们的能力.
The situation is that this bug seems to exhibit symptoms based on pure luck-of-the-draw project ordering in the solution file. It appears as if the solution file will just blindly build the projects in the order they appear, relying on its ability to detect unbuilt references and build them on demand when needed.
在我的特定解决方案文件中，我的 Wix 项目是在我的 Wpf 应用程序项目之前订购的.这导致首先构建 Wix 项目，虽然正确检测到对 Wpf 项目的依赖，但由于未定义的 $(BuildProjectReferences) 变量而跳过了实际的 MSBuild 任务，我在本文的主要帖子中提到了几条评论线.由于 MSBuild 冗长仍处于诊断状态，BuildProjectReferences 可以被视为未定义的构建 Wix 项目，并且可以在构建 Wix 项目的任务中构建 Wpf 项目时将其定义为 true.然而，在测试时，它再次评估 undefined，任务被跳过，Wix 构建失败，因为它找不到未构建的 Wpf 项目的构建输出.
In my particular solution file, my Wix project was ordered before my Wpf application project. This resulted in the Wix project being built first, and while the dependency on the Wpf project was detected correctly, the actual MSBuild task was skipped because of the undefined $(BuildProjectReferences) variable I mention a couple of comments down from the main post in this thread. With MSBuild verbosity still on diagnostic, BuildProjectReferences can be seen as undefined building the Wix project, and it can be seen defined as true upon building the Wpf project within the task to build the Wix project. Yet, when tested, it evaluates undefined again, the task is skipped, and the Wix build fails because it can't find the build output of the unbuilt Wpf project.
所以最重要的是:由于 $(BuildProjectReferences) 变量错误，项目依赖被跳过.有趣的是，这个变量只存在于 Wix2010.targets 文件中，而不存在于 wix.targets 中；我想这就是为什么在我安装 Tfs2010 和 Vs2010 后才出现这种情况的原因.
So bottom line: project dependency is skipped because of bad $(BuildProjectReferences) variable. Interestingly, this variable is present only in the Wix2010.targets file, and not in wix.targets; I guess that's why this is just showing up after I installed Tfs2010 and Vs2010.
解决方案:如何确保将 BuildProjectReferences 正确传递给后续的 MSBuild 任务?变量作用域有什么特别之处吗?
The solution: How do I make sure that BuildProjectReferences is passed along correctly to the subsequent MSBuild tasks? Is there something special with variable scoping going on?
2010-09-14:在 WiX 工具集中针对此问题打开了一个错误:http://sourceforge.net/tracker/?func=detail&atid=642714&aid=2990231&group_id=10>5前一阵子.希望这不再是问题.如果是这样，请打开一个新的错误.
2010-09-14: A bug was opened for this issue in the WiX toolset: http://sourceforge.net/tracker/?func=detail&atid=642714&aid=2990231&group_id=105970 and fixed a while ago. Hopefully, this is no longer an issue. If so, please do open a new bug.
为了直接解决您的评论，我的解决方案中没有任何内容在其构建文件中包含 AnyCPU 配置.我创建 AnyCPU 配置只是为了测试我在原始帖子中链接到的线程建议的解决方案.在它不起作用后，我再次删除了 AnyCPU 配置.
To address your comment directly, nothing in my solution has an AnyCPU configuration in their build files. I created the AnyCPU configurations only to test the solution suggested by the thread I linked to in my original post. After it didn't work, I removed the AnyCPU configurations again.
此外，这些项目位于同一个解决方案文件中，但如果重要的话，它们位于不同的解决方案文件夹(接口文件夹、安装程序文件夹)中.
Furthermore, the projects are in the same solution file, however in separate solution folders (interface folder, installer folder) if that matters.
有趣的是，我打算制作一个小沙盒示例，以便说明我遇到的问题，但是在创建我的小示例解决方案后，我无法重现错误.这让我觉得这可能是使用从 Tfs2008 团队项目升级的团队项目而不是在 Tfs2010 中全新创建的团队项目的结果.如果我无法弄清楚测试解决方案的工作原理，我可能会尝试将我的项目分支到一个新的项目中来测试这个理论.
Interestingly enough, I was going to make a small sandbox example so that I could illustrate the problem I was having, however after creating my tiny sample solution, I couldn't get the error to reproduce. This makes me think that perhaps this is a result of using a team project that was upgraded from a Tfs2008 team project rather than one that was created fresh in Tfs2010. I may try branching my project into a new one to test this theory if I can't figure out why the test solution works.
附言另外，我是 stackoverflow 的新手——如果回答你自己的问题"工作流程只是为了提供具体的答案，那么为什么评论长度有限?
p.s. also, I'm new to stackoverflow--why on earth are comments limited in length if the "answer your own question" workflow is intended only to provide concrete answers?
因此，我今天将构建详细程度提高到诊断并通读了它，其中有一行对我来说特别突出:
So I threw the build verbosity up to diagnostic and read through it today, and one line in particular stood out to me:
Task "MSBuild" skipped, due to false condition; ('@(_ProjectReferenceWithConfiguration)'!='' and '$(BuildingInsideVisualStudio)' != 'true' and '$(BuildProjectReferences)' == 'true' and '@(_MSBuildProjectReferenceExistent)' != '') was evaluated as ('..\WpfApp\WpfApp.csproj'!='' and '' != 'true' and '' == 'true' and '..\WpfApp\WpfApp.csproj' != '').
这被视为我的安装程序项目正在尝试构建我的 wpf 项目，因为 wpf 项目被引用.特别是，出于某种原因，$(BuildProjectReferences) 在我相当确定它应该为true"时评估为 ''.
This was seen as my installer project was attempting to build my wpf project since the wpf project is referenced. In particular, for some reason $(BuildProjectReferences) is evaluating to '' when I'm fairly sure it should be 'true'.
但是在日志的前面，在 WpfApp 项目的 MSBuild 任务开始时，我看到了这一点:
However earlier in the log, at the beginning of the MSBuild task for the WpfApp project, I saw this:
Task "MSBuild" (TaskId:15)
...
Initial Properties:
...
BuildProjectReferences = true
所以属性在任务开始之前确实是正确的，但后来显然被覆盖了?我有点不清楚这些属性是如何设置的.
So the property was indeed correct up until the beginning of the task, but then was apparently overwritten? I'm sort of unclear as to how these properties get set.
推荐答案
根据 Rob Mensching 对我原帖的编辑，这似乎最迟在 WiX 3.6.0917.0 中得到了修复.
Following Rob Mensching's edit of my original post, it seems that this has indeed been fixed in WiX 3.6.0917.0 at the latest.
这篇关于为什么 Tfs2010 先构建我的 Wix 项目?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！