Управление зависимостями сборки .NET по dll-ссылке, а не по проекту в VS

Question

У нас есть проект .NET, состоящий из нескольких подпроектов (около 20). Существует несколько решений, каждое из которых содержит только те подпроекты, которые относятся к конкретному решению.

Чтобы учесть произвольные решения, наши подпроекты никогда не ссылаются друг на друга посредством ссылок на проекты, а скорее посредством прямых ссылок на dll. Файл csproj немного подправлен, чтобы HintPath включал $ (Configuration), поэтому сборки Debug ссылаются на dll отладки, а сборки выпуска - на dll выпуска.

Все отлично работает, но есть две основные проблемы - одна раздражает, а другая очень острая:

1. VS не распознает ссылки dll для целей расчета зависимости. Мы должны вручную указывать зависимости с помощью диалога «Project Dependencies» каждый раз, когда добавляется новый проект или ссылка. Это раздражает.
2. Мы не используем ни Resharper, ни Visual Assist (отличные инструменты, но мы их не используем, это данность). Нам нравится использовать стандартную команду «Browse to Definition» (например, доступную из контекстного меню исходного кода). Острая проблема заключается в том, что он работает только между проектами, если один проект ссылается на другой, используя ссылку на проект, и не работает, когда ссылка является прямой ссылкой dll, , даже если указанный проект включен в решение ! Это настоящий облом, потому что вместо перехода к источнику он перемещается к метаданным.

Я ищу совета у тех людей, которые используют ссылки dll, такие как мы, и каким-то образом преодолели эти две проблемы. Спасибо.

EDIT:

Обратите внимание, что, помимо проблемы «Обзор к определению», наличие Dll-ссылок вместо ссылок на проект обуславливает только одну временную стоимость для менеджера проекта, которая заключается в обновлении зависимостей проекта каждого затронутого решения при добавлении нового проекта или новая зависимость должна быть введена. Эти зависимости проекта сохраняются в файле .sln и не требуют никакого обслуживания, пока не прибудет новый проект или не будет создана новая зависимость, что случается не так часто.

Мы используем msbuild для построения наших проектов на CI-сервере, который использует те же файлы .sln, что и VS. Существует один основной файл .sln, который включает все подпроекты.

Я хотел бы подчеркнуть более острую проблему - неспособность перейти к определению в другом проекте, хотя оба проекта находятся в одном решении только потому, что ссылки являются ссылками dll. Это раздражает, и это неприятно, нет никаких причин, почему VS настаивает на ссылках на проекты, чтобы включить эту функцию. Другие инструменты, такие как Resharper или Visual Assist, не имеют этого ограничения. Увы, у нас нет этих инструментов и вряд ли будет в обозримом будущем.

Answer 1

Проблема с вашей конфигурацией сборки заключается в следующем: скажем, у вас есть 3 проекта и 2 решения.

Solution1
- Project1
- Project2
Solution2
- Project1
- Project3

Внезапно сборка Solution2 создает часть кода для Solution1, оставляя его в недопустимом состоянии (последние двоичные файлы либо несовместимы, либо их не требуется создавать).

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

Подводя итог, вы должны уделить некоторое время и реструктурировать свои решения, чтобы выполнить следующие условия:

• Каждый проект входит в одно решение.
• Если проект зависит от другого проекта в том же решении, сделайте его ссылкой на проект.
• Если проект зависит от другого проекта в другом решении, сделайте его ссылкой на DLL.

В дополнение к вышесказанному, я рекомендую создать каталог "Externals" для размещения сборок, когда на них ссылаются другие решения. Допустим, вы реструктурировали следующее:

Solution1
- Project1
- Project2 -> reference project Project1
Solution2
- Project3 -> reference Project1.dll

В этом случае вы должны поместить копии Project1.dll и Project1.pdb в Externals\Project1\Debug и Externals\Project1\Release и ссылку External\Project1\$(Configuration)\Project1.dll в Project3. Обновляйте сборки в каталоге Externals только тогда, когда вы готовы передать сборку всем другим решениям.

Answer 2

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

Answer 3

Мне кажется, что проблемы, с которыми вы сталкиваетесь, являются прямым результатом неправильного использования набора инструментов. В Visual Studio нет другого способа автоматического расчета зависимостей проекта, если вы не позволяете ему управлять ими.

Похоже, у вас есть два варианта.

1. Использование Visual Studio для управления зависимостями проекта
2. Использовать другую систему сборки (например, NAnt)

Похоже, вы исключили вариант # 1, поэтому я не буду больше это обсуждать. Так что остается только вариант № 2.

Вы можете использовать NAnt для создания ваших отдельных проектов CSproj и использовать скрипт сборки NAnt для определения зависимостей между проектами. У этого есть два недостатка.

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

С другой стороны, Visual Studio не смог бы скомпилировать ваше решение в целом, поскольку эта логика была бы перенесена из VS в сценарий внешней сборки. Это может привести к путанице среди разработчиков и помешать процессу отладки. Не сказать, что это невозможно преодолеть ... просто сказать, что на этих этапах процесса разработки потребуется дополнительная настройка.