MSBuild строит проекты с ссылками на проекты правильно, но не из решения

Question

Когда я собираю A.sln, который включает в себя 2 проекта B.csproj и C.csproj, которые имеют внутренние ссылки на проекты, он выдает ошибки ссылок в MSBuild. Но когда я собираю B.csproj и C.csproj отдельно в MSBuild, он не выдает ошибок. А также сборка A.sln в VS IDE также не выдает ошибок. Я использую .NET 2.0 framework. Ниже приведены скрипты, используемые для сборки sln и projs.

MSBuild "<path>/A.sln" /p:Configuration=Release /p:StartupObject="" /p:WarningLevel=4 /p:Optimize=true /t:rebuild /l:Filelogger,Microsoft.Build.Engine;logfile=F:\A.sln.log /verbosity:normal

MSBuild "<path>/B.csproj" /p:Configuration=Release /p:StartupObject="" /p:WarningLevel=4 /p:Optimize=true /t:rebuild /l:Filelogger,Microsoft.Build.Engine;logfile=F:\B.csproj.log /verbosity:normal 

MSBuild "<path>/C.csproj" /p:Configuration=Release /p:StartupObject="" /p:WarningLevel=4 /p:Optimize=true /t:rebuild /l:Filelogger,Microsoft.Build.Engine;logfile=F:\C.csproj.log /verbosity:normal 

Edit:

Все ошибки вызываются из кода для отсутствующих ссылок (все являются ссылками проекта). Я получаю только три типа ошибок, как указано ниже.

ошибка CS0012: определен тип 'X' в сборке, на которую нет ссылок. Вы должны добавить ссылку на сборку 'Y, версия = 2.0.0.0, культура = нейтральная, PublicKeyToken = aad4cbe5d7c27078' .

ошибка CS0234: тип или пространство имен Имя «Х» не существует в пространство имен 'Y' (вы пропустили ссылка на сборку?)

ошибка CS0246: тип или пространство имен имя 'X' не может быть найдено (вы отсутствует директива использования или ссылка на сборку?)

Я очистил все ранее созданные библиотеки от путей сборки перед сборкой из IDE и MSBuild. Но IDE просто отлично работает и не показывает отсутствующий индикатор ссылки в разделе «Ссылки» для проекта.

В IDE вручную не добавлены ссылочные пути.

Еще одно обновление:

Я только что заметил, что, когда я открываю оба проекта из решения, ссылки правильно указываются в IDE. Но когда я открываю проекты отдельно в IDE, недостающие ссылки, о которых я упоминал, встречаются в MSBuild. Очень странный.

Итак, подведем итог,

Buiilding .proj в MSBuild - Хорошо

Создание .proj в IDE - Ошибка

Buiilding .sln в MSBuild - Ошибка

Buiilding .Sln в IDE - Хорошо

Выглядит очень странно для меня. Помощь очень ценится.

Answer 1

MSBuild и VS используют ссылки проекта и зависимости проекта для выбора порядка сборки решения. Кроме того, он не определен - и, как правило, отличается между двумя. Проверьте, что оба они верны. Зависимости проекта задаются в свойствах вашего решения. Если это не сработает, проверьте, что идентификаторы GUID в ссылках проекта в ваших проектах совпадают с указанными в решении. Иногда воссоздание решения может исправить их.

Answer 2

Для меня, когда у меня была эта (или похожая) проблема, ручная проверка (и исправление) набора направляющих решает мою проблему. Раздражает отслеживание направляющих между файлами .sln и .csproj, но это работает.

Обычно я удаляю ссылку на проект и добавляю ее заново, и это решает проблему (как только я обнаружил несоответствующие несоответствующие руководства) Может быть, я должен сначала попробовать это. Это проще.

Answer 3

Некоторые моменты, на которые следует обратить внимание: создание решения в IDE - это не то же самое, что запуск MSBUILD для файла .sln. Вместо этого вы можете попробовать использовать devenv.exe / rebuild A.sln. Среда IDE играет несколько игр, позволяющих создавать файл .sln, включая создание "эквивалентного" проекта в стиле MSBUILD.

Кроме того, среда IDE не просто напрямую порождает команды MSBUILD. Существует взаимодействие между ними для повышения производительности. Например, задачи CSC в проекте, вероятно, выполняются внутри IDE, а не в виде отдельных сборок командной строки, как MSBUILD породил бы их.

Вам также следует рассмотреть возможность получения Process Monitor от http://technet.microsoft.com/sysinternals/, чтобы посмотреть, к каким файлам осуществляется доступ.

Answer 4

Удалите сборку из GAC (папка C: \ WINDOWS \ Assembly - выберите сборку, щелкните правой кнопкой мыши и удалите).

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

Answer 5

Как упоминал Джон Скит, сообщение об ошибке было бы полезно узнать, в чем проблема. Однако без каких-либо подробностей, если он встроен в IDE, но не встроен в MSBuild, похоже, что у вас могут быть библиотеки DLL, на которые вы ссылаетесь в своих проектах, которые недоступны в пути, по которому вы строите решение. Возможно, вы вручную копировали их в то место, где IDE могла их найти, или в вашей IDE были настроены ссылочные пути для поиска в определенной папке.

Просто кое-что проверить, пока вы спрашиваете другие детали.

РЕДАКТИРОВАТЬ: Теперь, когда есть некоторые детали, это может быть проблема порядка сборки. Есть ли в проекте B ссылка на проект C? Если это так, возможно, вам просто нужно изменить порядок сборки проекта C перед проектом B.