Почему сборка VS2008 отличается от msbuild для того же решения?

Я унаследовал решение, состоящее из нескольких проектов, смесь VB.NET и C #. Он прекрасно работает с помощью кнопки "Построить решение" в среде IDE. Он не собирается из командной строки с использованием "msbuild foo.sln"; сообщение об ошибке указывает, что проект A (который ссылается на проект B) не может найти проект B. Действительно, после изучения содержимого папки «bin» после использования «msbuild» и сравнения ее с содержимым после использования IDE я могу найти много пропавших без вести DLL, в том числе B.dll.

Вкратце: проект A имеет ссылку на проект B, но B.DLL копируется только в каталог bin A при использовании IDE, но не при использовании msbuild. Если я запускаю msbuild после сборки IDE, она работает, так как указанные библиотеки DLL копируются.

Я наивно полагал, что msbuild foo.sln - это то же самое, что и сборка IDE для foo.sln. Кажется, это не так. Есть еще как минимум три подобных вопроса о переполнении стека, но я не могу сослаться на них, потому что «новые пользователи могут публиковать только одну гиперссылку» (!!). Сожалею. Вот названия вопросов, чтобы вы могли искать себя:

Теперь вот мои вопросы:

  1. Где я могу найти документально подтвержденную информацию о том, что Visual Studio делает, когда вы "Build Solution"?
  2. Каковы рекомендации по настройке Visual Studio и сервера Continuous Integration (например, Hudson), чтобы сборки рабочих станций разработчика были такими же, как сборки CI?
    • Должны ли мы настроить сервер CI для использования devenv, как предложено Джоном Сондерсом, выше?
    • Или мы должны написать сценарий MSBuild для Visual Studio для использования в соответствии с предложением http://brennan.offwhite.net/blog/2007/05/31/running-msbuild-from-visual-studio/ ?
    • Что-то другое ...?

Я из мира Unix, так что не стесняйтесь присылать мне указатели новичков.

13.10.2009 03:47:08
2 ОТВЕТА

По моему мнению, вы должны создавать свои CI-скрипты и общие скрипты для сборки с помощью msbuild.

Среда IDE не использует тот же движок для сборки все время, что и движок msbuild, хотя я думаю, что они работают над этим все больше и больше.

0
13.10.2009 04:33:32

Джон Уэлдун прав, сборки из Visual Studio и MSBuild очень похожи, но иногда могут отличаться. Одним из случаев является то, что VS является более уступчивым по отношению к референсам. Допустим, у вас есть три проекта A, B и C. A зависит от B, а B зависит от C. Затем в VS, если проект A просто ссылается на B, тогда все в порядке, но MSBuild может жаловаться, потому что отсутствует ссылка на проект C. Один из основные причины, по которым существует некоторое различие, заключаются в том, что в VS имеется главный компилятор, который используется для облегчения работы с IDE. Если вы хотите понизить свой интерфейс IDE, вы можете установить для свойства MSBuild UseHostCompilerIfAvailable значение false, чтобы заставить Visual Studio использовать MSBuild. Такие как

<PropertyGroup>
    <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>
</PropertyGroup>

Я не предлагаю этого, но если вам это абсолютно необходимо, опция доступна для вас.

3
13.10.2009 04:40:51
Что касается проблемы транзитивного замыкания: у меня есть проект A, зависящий как от B, так и от C, а также проект B, зависящий от C. Все еще не удается.
Steve Robbins 13.10.2009 05:33:01
Хороший ответ, я ненавижу тот факт, что Visual Studio не использует исключительно msbuild, она создает всевозможные проблемы на серверах непрерывной сборки и т. Д., Когда люди используют файл .sln в качестве файла сборки, а не свои собственные, я часто устанавливаю UseHostCompilerIfAvailable в false, но я склонен делать это только при окончательной сборке перед фиксацией в хранилище.
krystan honour 14.10.2009 20:44:59