2010-04-16 75 views
11

大约一年前,一个类似的问题被问及并得到了回答,但要么是一个不同的问题(一切都处于测试阶段)或被误诊。它位于:MSbuild task fails because "Any CPU" solution is built out of order为什么Tfs2010在其他任何东西之前构建我的Wix项目?

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

该问题最初是在解决方案中只有两个平台定义时遇到的; x86和x64。也有两种风格,Debug和Release,并且TFSBuild.proj被设置为构建所有四种组合。任何地方都没有AnyCPU出现。根据上面提到的问题,我尝试将Wpf项目更改为使用AnyCPU,以便首先构建它。此时,wix项目使用了确切的配置,而Wpf项目使用AnyCPU的风格。但是,这样做似乎没有改变任何事情。

我正在使用Tfs2010 RTM,Vs2010 RTM和最新版本的Wix,它们在撰写本文时是从2010-04-02开始的3.5.1602.0。任何其他人遇到这个?

2010-04-27:相当程度的挖掘,并再现克隆VM构建机器上后,我相信我知道发生了什么事情,也什么是失败,但我不太知道如何解决它。

情况是,该错误似乎表现出基于解决方案文件中纯粹绘制运气的项目排序的症状。看起来好像解决方案文件只是盲目地按照它们出现的顺序构建项目,依赖于它能够检测未构建的引用并在需要时按需构建它们。

在我特别的解决方案文件中,我的Wix项目是在我的Wpf应用程序项目之前订购的。这导致Wix项目首先被构建,并且正确地检测到对Wpf项目的依赖关系,但实际的MSBuild任务因为未定义的$(BuildProjectReferences)变量而被忽略,我提到了这篇文章主要文章中的一些评论线。由于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中创建的团队项目的结果。如果我无法弄清楚测试解决方案的工作原理,我可以尝试将我的项目分支到一个新项目中来测试这个理论。

p.s.另外,我是新来的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)正在评估为'',当我确信它应该是'真实的'。

在日志中但是前面,在MSBuild任务的WpfApp项目开始时,我看到了这一点:

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

所以财产确实是正确的,直到任务的开始,但随后被显然被覆盖?我不清楚这些属性是如何设置的。

+0

我遇到了同样的问题,但仍未能解决它。 – 2010-04-21 13:56:05

+0

我已经做了一些研究。从头开始重新创建解决方案似乎可行,我认为这可能与订单项目添加到解决方案中有关。这是纯粹的猜测,虽然... – 2010-04-21 14:56:47

+0

编辑原始问题描述与更多信息。 – bwerks 2010-04-27 19:35:10

回答

4

继Rob Mensching编辑我原来的帖子之后,似乎这确实已经在最新的WiX 3.6.0917.0中得到了修复。

1

TFS使用一组属性来控制要构建的解决方案和配置的名称(遍历)。对于解决方案和配置的每个组合,它随后使用项目依赖性/构建顺序来控制构建项目的顺序。有可能您的EXE/DLL是AnyCPU,并且您的WiX是x86,并且虽然WiX对EXE/DLL有依赖关系,但x86是在您的AnyCPU之前构建的。或者,他们甚至可能采用不同的解决方案,所以如果没有查看源代码就很难说清楚,但基本上它是如何工作的。

16

它的一个错误,一个错误,一个错误。不知道谁是负责任的,但这里有一个工作肮脏的肮脏的黑客:

  1. 在记事本中打开您的.sln文件。
  2. 在项目列表中找到您的wix项目。
  3. 剪掉它们,在所有其他项目列出后粘贴回来。
  4. 在淋浴时哭泣,因为你试图擦洗脏衣服,只有几个小时后出现,摩擦生,仍然与恶臭的恶臭紧紧地像你的尸体的皮肤。
+0

是的,我自己试图想出一个简单的复制场景(其目的实际上是在此处发布代码),但我毫不犹豫地称其为解决方案。 “哦,所有其他我依赖的项目*都已经建成了吗?真糟糕!” 是的,这完全糟透了。然而,这是迄今为止我在这个网站上得到的最好回应,呵呵。 – bwerks 2010-05-01 00:24:09

+0

感谢您的解决方法。 – 2010-06-03 17:53:20

+0

@Nich奇怪的是,当我遇到与另一个解决方案相同的错误时,我不得不重新学习这个肮脏的黑客攻击。再来一次,我会拍下它。 – Will 2010-06-03 23:29:02

1

我们所做的是首先report the bug to wix然后我们发现你的问题。

我们通过说,默认情况下,wix项目将建立引用,我们解决了问题。我们更新了文件C:\ Program Files \ MSBuild \ Microsoft \ WiX \ v3.5 \ wix2010。通过在设置路径的项目中设置<BuildProjectReferences>True</BuildProjectReferences>来实现目标。所以,是的,我们手动完成了这个工作。我们已经报告了该错误以及我们的修复程序。

3

我看到这个问题(wix 3.7找不到依赖项目输出)在我的本地和TFS构建(VS2010和VS2012)。

我终于通过将msbuild属性/m:1设置为只使用一个构建过程来解决它。我设置了/m以允许msbuild找出它可以用来同时构建多少个进程。

+1

不是最好的解决方案(因为我想追踪错误),但是我遇到过的唯一有效的解决方案。 TFS2013/wix3.8有同样的问题,这有帮助。 – 2014-05-15 12:30:19

+0

ps忘了补充:一直在浏览论坛很多小时,这两个线程可能是我的救生员,但他们不是:http://blogs.msdn.com/b/msbuild/archive/2010/12/21/incorrect -solution-build-ordering-when-using-msbuild-exe.aspx?CommentPosted = true#commentmessage and http://social.msdn.microsoft.com/Forums/vstudio/en-US/dc5b35a3-655f-4329-8da4 -50f21153a9a2 /预生成事件,似乎对运行在最错误的时间?论坛= tfsbuild – 2014-05-15 12:37:34

0

我今天面临着一个同样的问题,找到这样一个解决方案:

在记事本中打开您的解决方案文件中找到你的安装项目,并更改项目后设置。这将告诉msbuild这个项目应该等待另一个项目的构建。我不知道为什么,但它不是默认添加的。

Project("{GUID}") = "MyInstaller", "MyInstallerPath", "{Installer Project GUID}" ProjectSection(ProjectDependencies) = postProject {Prebuild Project GUID} = {Prebuild Project GUID} EndProjectSection EndProject

“预生成项目GUID”是你要安装的项目的权数。

相关问题