Подобный вопрос был задан и получен ответ около года назад, но это была либо другая проблема (все было в бета-версии), либо ошибочный диагноз. Он находится здесь: Сбой задачи MSbuild, поскольку решение «Любой ЦП» построено не по порядку .
Моя проблема в том, что у меня есть проект установщика wix, и после обновления до Tfs2010 в понедельник сборка завершается неудачно при связывании, потому что она не может найти продукт сборки приложения Wpf в проекте. После некоторых копаний, это потому, что он еще не построен. Сборка в Vs2010 работает как обычно. Проект wix настроен на зависимость от проекта Wpf, и при просмотре порядка сборки проекта в IDE все выглядит как обычно.
Проблема изначально возникла только с двумя определениями платформы в решении; х86 и х64. Существует также два варианта: Debug и Release, и TFSBuild.proj настроен на сборку всех четырех комбинаций. AnyCPU не было нигде. Согласно приведенному выше вопросу, я попытался изменить проект Wpf для использования AnyCPU, чтобы он был построен первым. На этом этапе проект wix использовал точную конфигурацию, а проект Wpf использовал вариант с AnyCPU. Однако это, похоже, ничего не изменило.
Я использую RTM 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. Я могу попробовать разложить мой проект на новый, чтобы проверить эту теорию, если не могу понять, почему работает тестовое решение.
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) оценивается как '', когда я уверен, что это должно быть 'true'.
Однако ранее в журнале, в начале задачи MSBuild для проекта WpfApp, я увидел это:
Task "MSBuild" (TaskId:15)
...
Initial Properties:
...
BuildProjectReferences = true
Значит, свойство действительно было правильным до начала задания, но затем было явно перезаписано? Мне не совсем понятно, как эти свойства устанавливаются.