MSBuild - может ли он работать с зависимостями проекта в файле решения? Если да, то как?

У меня есть проект msbuild, который строит SLN файл из visual studio, который содержит все проекты в (около 70+ проектов), и многие проекты зависят друг от друга, что нужно их строить по порядку - иногда разработчик забывает задавать порядок сборки вручную в visual studio в файле решения, что приводит к сбою msbuild в чистом решении, поскольку что-то получается из заказа/не может найти dll.

Есть ли способ для msbuild принимать все проекты и разрабатывать зависимости и строить проекты в порядке, если есть, как это сделать? используя задачу MSBuild? С текущими попытками кажется, что он просто строит в порядке, в котором он читает проекты, если я передаю список файлов проектов + пути.

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

Кто-нибудь решил/видел это раньше?

Ответ 1

Как вы называете MSBuild? Если вы укажете MSBuild в файл решения, он должен иметь возможность определять зависимости. Если вы укажете его на отдельные файлы проекта, то он не сможет разрешить ссылки на проекты.

Если вы не используете ссылки на проект, вы все равно можете контролировать порядок зависимостей в решении, используя диалог "Зависимости проектов", чтобы вручную устанавливать зависимости.

Ответ 2

В то время как зависимостей проекта трудно поддерживать и не использовать в файлах .sln, ссылки на проекты соблюдаются и постоянно определяют порядок: см. задачу ResolveReferences в Microsoft.Common.targets.

ASIDE: "Мой друг" может "во время рефакторинга" случайно удалил свою сборку Task и ее DependsOnTargets привязку к задаче Microsoft.Common.targets ResolveReferences и закончил с ProjectReferences не которые звучат как вопрос здесь. Если вы читаете некоторые из сообщений, вы можете понять, что все это безумно шаткое - это не так; дрожащие биты являются зависимыми от проекта, а не ссылками на Project.

См. эту отличную статью в блоге MSDN от Dan Moseley, которая действительно объясняет эту тему, включая некоторые полезные стратегии обхода. (через эту небольшую проблему со зданием xUnit.net).

Ответ 3

Если все ваши зависимые проекты находятся в решении и вы используете ссылки на Project, Visual Studio должна управлять зависимостями для вашего и строить в порядке этого списка зависимостей.

Похоже, вы не используете ссылки на проекты. Я всегда рекомендую ссылки на проекты.

Ответ 4

Это старый вопрос, но проблема была скорее всего в том, что проекты в решении использовали прямые ссылки на зависимые DLL (Добавить ссылку > выберите вкладку "Обзор" > выбрать зависимую DLL) вместо использования ссылок на проекты (Добавить ссылку), выберите вкладку "Проекты" > выберите зависимый проект). С помощью прямых ссылок Visual Studio не может определить цепочку зависимостей. Вы должны сказать это, щелкнув правой кнопкой мыши по решению node и выберите "Свойства". Выберите "Общие свойства" > "Зависимости проекта", чтобы установить необходимые проекты. Г-н Клаус прав, но я хотел бы документировать, как решить эту проблему.

Ответ 5

Хотя правильно, что MSBuild должен соблюдать порядок сборки при использовании зависимостей проекта, существует одна оговорка. В настоящее время он не наблюдает за порядком обратного построения при создании чистой цели (так как я написал о здесь). Однако для регулярной сборки он работает хорошо, как описано другими.

Ответ 6

Я использую Msbuild 4, найденный в c:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Кажется, проблема решена.

Ответ 7

Нет инструмента Microsoft, который рассмотрит все зависимости ваших 70+ проектов и создаст файл решения с явно объявленными вами зависимостями.

Вы должны сделать это самостоятельно, используя два разных метода:

Вручную укажите зависимость для решения в визуальной студии.
Укажите ссылку на проект в самом файле проекта.

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

В какой-то момент я этого не делал, и у меня было 600 проектов в сборке. Поэтому я написал инструмент (годы назад), который автоматизировал бы 99% этой работы. Он использует .NET MSBuild API для чтения файлов msbuild (без воссоздания колеса здесь с xml api). Затем он анализирует выходы и входы и генерирует дерево зависимостей, которое затем я могу сделать с ним несколько вещей:

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

Единственное ограничение, которое я видел с помощью инструмента, - это несколько сумасшедших зависимостей COM, которые в любом случае довольно отрывочны. Который я добавил супер простую работу.