为什么 Tfs2010 会先构建我的 Wix 项目? [英] Why does Tfs2010 build my Wix project before anything else?

问题描述

大约一年前有人提出并回答了类似的问题，但要么是不同的问题(一切都处于测试阶段)，要么被误诊.它位于此处: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=105970 并修复了前一阵子.希望这不再是问题.如果是这样，请打开一个新的错误.

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 ('..WpfAppWpfApp.csproj'!='' and '' != 'true' and '' == 'true' and '..WpfAppWpfApp.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 项目?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！