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

Question

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

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

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

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

Answer 1

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

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

---

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

Answer 7

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