为什么 Tfs2010 首先构建我的 Wix 项目？
大约一年前，有人提出并回答了类似的问题，但要么是一个不同的问题（一切都处于测试阶段），要么被误诊。它位于此处： MSbuild 任务失败，因为“任何CPU”解决方案都是乱序构建的。
我的问题是我有一个wix安装程序项目，周一升级到Tfs2010后，构建链接失败，因为它在项目中找不到Wpf应用程序的构建产品。经过一番挖掘，原来是因为还没有建起来。在 Vs2010 中构建工作正常。 wix 项目设置为依赖于 Wpf 项目，并且在 IDE 中查看 Project Build Order 时，一切看起来都很正常。
该问题最初是在解决方案中只有两个平台定义时遇到的； x86 和 x64。还有两种风格：调试和发布，TFSBuild.proj 设置为构建所有四种组合。任何地方都没有出现 AnyCPU。根据上面提到的问题，我尝试更改 Wpf 项目以使用 AnyCPU，以便首先构建它。此时，wix 项目使用了精确的配置，Wpf 项目使用了 AnyCPU 的风格。然而，这样做似乎并没有改变什么。
我使用的是 Tfs2010 RTM、Vs2010 RTM 和 Wix 的最新版本（在撰写本文时为 2010 年 4 月 2 日发布的 3.5.1602.0）。还有其他人遇到这个吗？
2010-04-27：经过大量挖掘并在克隆的虚拟机构建机器上进行复制后，我相信我知道发生了什么以及失败的原因，但我不太知道如何修复它。
情况是，这个错误似乎表现出基于解决方案文件中纯粹的运气项目排序的症状。看起来解决方案文件只会按照项目出现的顺序盲目地构建项目，依赖于其检测未构建引用并在需要时按需构建它们的能力。
在我的特定解决方案文件中，我的 Wix 项目排在我的 Wpf 应用程序项目之前。这导致 Wix 项目首先被构建，虽然正确检测到了对 Wpf 项目的依赖关系，但由于未定义的 $(BuildProjectReferences) 变量，实际的 MSBuild 任务被跳过，我在这篇文章的主要帖子中提到了一些评论线。由于 MSBuild 详细信息仍在诊断中，BuildProjectReferences 可以被视为未定义的构建 Wix 项目，并且在构建 Wix 项目的任务中构建 Wpf 项目时可以被视为定义为 true。然而，在测试时，它再次评估未定义，任务被跳过，并且 Wix 构建失败，因为它找不到未构建的 Wpf 项目的构建输出。
所以底线：由于 $(BuildProjectReferences) 变量错误，项目依赖项被跳过。有趣的是，这个变量只存在于 Wix2010.targets 文件中，而不存在于 wix.targets 中；我想这就是为什么在我安装 Tfs2010 和 Vs2010 后才出现这个问题。
解决方案：如何确保 BuildProjectReferences 正确传递到后续的 MSBuild 任务？变量作用域有什么特别的地方吗？
2010-09-14：WiX 工具集中针对此问题提出了一个错误：http://sourceforge.net/tracker/?func=detail&atid=642714&aid=2990231&group_id=105970 不久前已修复。希望这不再是问题。如果是这样，请打开一个新的错误。
为了直接解决您的评论，我的解决方案中没有任何内容在其构建文件中包含 AnyCPU 配置。我创建 AnyCPU 配置只是为了测试我在原始帖子中链接到的线程建议的解决方案。不行后我又把AnyCPU配置去掉了。
此外，这些项目位于同一解决方案文件中，但如果重要的话，位于单独的解决方案文件夹（界面文件夹、安装程序文件夹）中。
有趣的是，我打算制作一个小沙箱示例，以便可以说明我遇到的问题，但是在创建我的小示例解决方案后，我无法重现错误。这让我觉得这也许是使用从 Tfs2008 团队项目升级的团队项目而不是在 Tfs2010 中全新创建的团队项目的结果。如果我无法弄清楚测试解决方案为何有效，我可能会尝试将我的项目分支到一个新项目来测试这一理论。
另外，我是 stackoverflow 的新手——如果“回答你自己的问题”工作流程只是为了提供具体的答案，那么到底为什么评论的长度有限呢？
因此，我今天将构建的冗长程度提高到诊断级别并通读了它，其中一行对我来说特别突出：
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”时，它的计算结果为“”。
然而，在日志的早期部分，在 WpfApp 项目的 MSBuild 任务开始时，我看到了这一点：
Task "MSBuild" (TaskId:15)
...
Initial Properties:
...
BuildProjectReferences = true
所以该属性在任务开始之前确实是正确的，但随后显然被覆盖了？我不太清楚这些属性是如何设置的。
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.
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.
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.
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: 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.
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.
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.
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: 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.
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.
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.
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' != '').
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'.
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这是一个错误，一个错误，一个错误。我不知道谁负责，但这里有一个肮脏的黑客：
Its a bug, a bug, a bug. I don't know, who is responsible, but here's a working dirty filthy hack:
我在我的本地和 TFS 构建（对于 VS2010 和 VS2012）中看到了这个问题（wix 3.7 找不到依赖的项目输出）。
我最终通过将 msbuild 属性
/m:1设置为仅使用单个构建过程来解决这个问题。我设置了/m来允许 msbuild 计算出它可以使用多少个进程来同时构建。I was seeing this problem (wix 3.7 not finding the dependent project output) in my local and TFS builds (for both VS2010 and VS2012).
I finally got around it by setting the msbuild property
/m:1to only use a single build process. I set/mto allow msbuild to figure out how many processes it could use to simultaneously build with.在 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.
我今天遇到了同样的问题，找到了这样的解决方案：
在记事本上打开解决方案文件，找到您的安装项目并更改 postProject 设置。这将告诉 msbuild 该项目应该等待另一个项目来构建。我不知道为什么，但默认情况下不添加它。
Project("{GUID}") = "MyInstaller", "MyInstallerPath", "{安装程序项目 GUID}"项目部分（项目依赖项）= postProject
{预构建项目 GUID} = {预构建项目 GUID}
结束项目部分
EndProject
'预构建项目 GUID' 是您要安装的项目右侧的数字。
I faced with a same problem today and find a solution like this:
Open your solution file on notepad the find your setup project and change postProject setting. This will tell msbuild this project should wait another project to build. I don't know why but it is not added by default.
Project("{GUID}") = "MyInstaller", "MyInstallerPath", "{Installer Project GUID}"ProjectSection(ProjectDependencies) = postProject
{Prebuild Project GUID} = {Prebuild Project GUID}
EndProjectSection
EndProject
'Prebuild Project GUID' is the number on the right of the project that you want to install.
TFS 使用一组属性来控制要构建（迭代）的解决方案和配置的名称。对于解决方案和配置的每种组合，它使用项目依赖项/构建顺序来控制项目构建的顺序。有可能您的 EXE/DLL 是 AnyCPU，而您的 WiX 是 x86，尽管 WiX 依赖于 EXE/DLL，但 x86 是在 AnyCPU 之前构建的。或者也许它们甚至处于不同的解决方案中，因此如果不查看源代码就很难判断，但这基本上就是它的工作原理。
TFS uses a set of properties to control the names of the solutions and configurations to build ( iterate through ). For each combination of solution and configuration it then uses the project dependencies / build order to control the order of the projects getting built. It's possible that your EXE/DLL's are AnyCPU and that your WiX is x86 and that although the WiX has a dependency on the EXE/DLL the x86 is built before your AnyCPU. Or maybe they are even in different solutions so it's kind of hard to tell without looking at your source but that's basically how it works.
我们所做的是首先向wix报告错误然后我们找到了你的问题。
我们解决了我们这边的问题，默认情况下，wix 项目将构建引用。我们通过在设置路径的项目中设置
True What we did is to first report the bug to wix and then we found your question.
We solved the problem on our side by saying that, by default, the wix project will build the references. We updated the file C:\Program Files\MSBuild\Microsoft\WiX\v3.5\wix2010.targets by setting
<BuildProjectReferences>True</BuildProjectReferences>in the project which set the path. So, yes, we have done this manually ; we have reported the bug as well as our fix.