Подобный вопрос был задан и получен ответ около года назад, но это была либо другая проблема (все было в бета-версии), либо ошибочный диагноз. Он расположен здесь:Сбой задачи MSbuild, потому что решение «Любой процессор» построено не по порядку.

Моя проблема в том, что у меня есть проект установщика wix, и после обновления до Tfs2010 в понедельник сборка завершается неудачно при связывании, потому что она не может найти продукт сборки приложения Wpf в проекте. После некоторых копаний, это потому, что он еще не построен. Сборка в Vs2010 работает как обычно. Проект wix настроен на зависимость от проекта Wpf, и при просмотре порядка сборки проекта в IDE все выглядит как обычно.

Изначально проблема возникла только с двумя определениями платформы в решении; х86 и х64. Существует также два варианта: Debug и Release, и TFSBuild.proj настроен на сборку всех четырех комбинаций. AnyCPU не было нигде. Согласно приведенному выше вопросу, я попытался изменить проект Wpf для использования AnyCPU, чтобы он был построен первым. На этом этапе проект wix использовал точную конфигурацию, а проект Wpf использовал вариант с AnyCPU. Однако, похоже, это ничего не изменило.

Я использую RTF Tfs2010, RTM Vs2010 и самую последнюю версию Wix, которая на момент написания этой статьи была 3.5.1602.0 от 2010-04-02. Кто-нибудь еще сталкивался с этим?

2010-04-27После большого количества копаний и воспроизведения на клонированной машине для сборки виртуальных машин, я думаю, я знаю, что происходит, а также что не получается, но я не совсем знаю, как это исправить.

Ситуация такова, что эта ошибка, кажется, проявляет симптомы, основанные на чистом упорядочении проекта в файле решения. Похоже, что файл решения будет просто слепо строить проекты в порядке их появления, полагаясь на свою способность обнаруживать не построенные ссылки и создавать их по требованию, когда это необходимо.

В моем конкретном файле решения мой проект Wix был заказан до моего проекта приложения Wpf. Это привело к тому, что проект Wix создавался первым, и хотя зависимость от проекта Wpf была правильно обнаружена, реальная задача MSBuild была пропущена из-за неопределенной переменной $ (BuildProjectReferences), о которой я упомянул пару комментариев из основного поста в этом нить. Поскольку многословность MSBuild все еще находится в состоянии диагностики, BuildProjectReferences можно рассматривать как неопределенную при построении проекта Wix, и его можно определить как истинное при построении проекта Wpf в рамках задачи по созданию проекта Wix. Тем не менее, при тестировании он снова оценивает неопределенное, задача пропускается, и сборка 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'.

Однако ранее в журнале, в начале задачи MSBuild для проекта WpfApp, я увидел это:

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

Таким образом, свойство действительно было правильным до начала задания, но затем было явно перезаписано? Я вроде неясно, как эти свойства устанавливаются.