Svn externals и c # сборки - несовместимы?

Question

что-то, что должно быть таким простым в .net, кажется слишком сложным.

У меня есть проект MyExtenders, содержащий несколько простых расширений для основных типов.

Многиепроекты используют MyExtenders - и поэтому в традиционном подходе svn checkout и build я добавляю MyExtenders как svn: external с ревизией, привязанной к той, в которой последний раз создавалась и тестировалась в.

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

Диаграмма, возможно, лучше всего объясняет зависимости:*

SolutionA
->ProjectA
->->MyExtenders r350 (svn:externed by ProjectA)
->ProjectB
->->MyCryptography r800 (svn:externed by ProjectB)
->->->MyExtenders r800 (svn:externed by MyCryptography)

Delphi / C отлично работает с вышеперечисленным - все ссылки взяты из их собственной папки проекта.

VS настаивает на потере структуры каталогов и выравнивании приведенного выше до:

SolutionA
->ProjectA (refers MyExtenders)
->ProjectB (refers MyCryptography)
->MyCryptography r800 (refers MyExtenders)
->MyExtenders r350 || r800 - my choice

И меня заставили изменить один из проектов, чтобы он ссылался на другой MyExtenders и другую ревизию.

Очевидно, я все делаю неправильно ... но как вы это делаете?право?

Answer 1

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

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

Эта проблема исчезнет, ​​если вы можете получить зависимые сборки, разделенные границей, например, интерфейс службы или канал удаленного взаимодействия.После этого вы можете самостоятельно устанавливать версии зависимостей.Однако Visual Studio не понравится иметь два проекта в одном решении с одинаковым именем, поэтому единственный способ обойти это - скопировать один из файлов проекта, переименовать его и загрузить в решение.