为什么Tfs2010先建立我的Wix项目？

Question

大约一年前问了一个类似的问题并回答了问题,但这个问题要么是一个不同的问题(一切都处于测试阶段),要么被误诊.它位于此处:MSbuild任务失败,因为"任何CPU"解决方案是按顺序构建的.

我的问题是我有一个wix安装程序项目,并且在星期一升级到Tfs2010后,构建在链接时失败,因为它无法在项目中找到Wpf应用程序的构建产品.经过一番挖掘,这是因为它还没有建成.Vs2010中的建筑工作正常.wix项目设置为依赖于Wpf项目,在IDE中查看Project Build Order时,一切看起来都很正常.

最初只遇到解决方案中的两个平台定义就遇到了这个问题; x86和x64.还有两种版本,Debug和Release,TFSBuild.proj设置为构建所有四种组合.任何地方都没有AnyCPU.根据上面引用的问题,我尝试更改Wpf项目以使用AnyCPU,以便首先构建它.此时,wix项目使用了确切的配置,Wpf项目使用了AnyCPU的flavor.但是,这样做似乎没有任何改变.

我正在使用Tfs2010 RTM,Vs2010 RTM和最新版本的Wix,在撰写本文时为2010年1月2日的3.5.1602.0.其他人遇到这个？

2010-04-27:在克隆的VM构建机器上进行了大量的挖掘和再现之后,我相信我知道发生了什么以及发生了什么失败,但我不知道如何解决它.

情况是,这个错误似乎表现出基于解决方案文件中纯粹的运气抽奖项目排序的症状.似乎解决方案文件只是按照它们出现的顺序盲目地构建项目,依赖于它能够检测未构建的引用并在需要时根据需要构建它们.

在我的特定解决方案文件中,我的Wix项目是在我的Wpf应用程序项目之前订购的.这导致了维克斯项目中第一个建成,而被正确检测到对WPF项目的依赖,实际MSBuild任务被跳过,因为未定义$(BuildProjectReferences)可变的我提了几个意见下来,从这个主哨线.随着MSBuild的详细程度仍然在诊断,BuildProjectReferences可以看作是不确定的建设维克斯项目,可以看出定义在建设任务中的WPF项目打造的维克斯项目为真.然而,在测试时,它再次评估undefined,跳过任务,并且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创建一个新的团队项目的结果.如果我无法弄清楚测试解决方案的工作原理,我可以尝试将我的项目分支到一个新项目来测试这个理论.

ps也,我是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)正在评估''当我非常确定它应该是'真'时.

但是在日志的早期,在WpfApp项目的MSBuild任务开始时,我看到了:

Task "MSBuild" (TaskId:15)
...
Initial Properties:
...
BuildProjectReferences = true

所以在任务开始之前,该属性确实是正确的,但后来显然被覆盖了？关于如何设置这些属性,我有点不清楚.

Answer 1

它是一个bug,一个bug,一个bug.Dunno谁负责,但这是一个工作脏肮脏的黑客:

1. 在记事本中打开.sln文件.
2. 在项目列表中找到您的wix项目.
3. 将它们剪切掉,并在列出所有其他项目后将其粘贴回来.
4. 当你试图擦去脏污时,在洗澡时哭泣,只是在几个小时之后出现,擦得很生,还有腐烂的恶臭,像尸体的皮肤一样紧贴着你.

Answer 2

我在我的本地和 TFS 构建（对于 VS2010 和 VS2012）中看到了这个问题（wix 3.7 找不到依赖的项目输出）。

我最终通过将 msbuild 属性设置/m:1为仅使用单个构建过程来解决这个问题。我设置/m允许 msbuild 计算出它可以使用多少个进程来同时构建。

Answer 3

在 Rob Mensching 对我的原始帖子进行编辑后，看来这个问题最近确实已在 WiX 3.6.0917.0 中得到修复。