Как мне ссылаться на сборки из другого решения? - PullRequest
8 голосов
/ 05 марта 2012

У меня есть два сценария:

  1. Для компании существует проект Framework, и для всех проектов мы собираемся использовать этот Framework.

  2. Существует специальный каркасный проект, специфичный для клиента, и только некоторым сотрудникам компании может понадобиться использовать эту DLL.

Обе платформы хранятся в отдельных решениях в TFS.

Как использовать ссылки на другие проекты? Должен ли я поставить обе сборки на GAC или что-то? Должен ли я скопировать выходную сборку вручную? Что рекомендуется, почему и как я его использую?

Ответы [ 5 ]

6 голосов
/ 05 марта 2012

Пользовательская структура

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

Общая структура

Я бы использовал nuget вместо GAC в любое время, поскольку вы избавляетесь от каких-либо проблем с версиями или необходимости создавать отдельный установочный пакет для фреймворка (поскольку вы GAC)

Легко создатьчастный сервер nuget.Просто создайте новый проект MVC3 и установите пакет сервера nuget: http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

5 голосов
/ 05 марта 2012

Добавьте указанную сборку в папку библиотеки в других проектах и ​​обновите ее вручную.При частом обновлении рассмотрите возможность использования своего собственного канала NuGet.

4 голосов
/ 06 марта 2012

Звучит для меня как классическая референция проекта, а также бинарная референция решений.Не используйте GAC.

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

|___$/3rdParty/
|     |__BaseFramework.dll
|     |__CustomFramework.dll
|     |__log4net.dll
|     |__WPFToolkit.dll
|
|___$/Sources/ProjectName/NormalProject.sln
|                         |
|                         |__[Binary Reference] "../../3rdParty/BaseFramework.dll"
|                         |__[Project Reference]
|                         |__[Project Reference]
|
|___$/Sources/Common/BaseFramework.sln
|                    |
|                    |__[Project Reference]
|                    |__[Project Reference]
|                    |__[Project Reference]
|                    |__[Project Reference]
|
|___$/Sources/Custom/Acme/AcmeProject.sln
|                         |
|                         |__[Binary Reference] "../../../3rd-party/CustomFramework.dll"
|                         |__[Project Reference]
|                         |__[Project Reference]
|
|___$/Sources/Custom/CustomFramework.sln
                    |
                    |__[Project Reference]
                    |__[Project Reference]
                    |__[Project Reference]
                    |__[Project Reference]

1 голос
/ 05 марта 2012

Итак, # 2 пользовательский проект Framework такой же, как # 1, но настроен для конкретного клиента?

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

На мой взгляд, преимущество превращения в ветвь состоит в том, что вы сможете легче объединять изменения между двумя ветвями.Представьте, что исправление ошибки или новая функция сделаны в # 1 и также должны быть применены к # 2;TFS должен быть в состоянии сделать это проще, при условии, что TFS знает, что # 2 - это просто ветвь # 1.

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

Я бы скопировал сборки Framework в папку в папке решения других ваших проектов.Я обычно называю мои "Зависимости", но это действительно не имеет значения.Пусть ваши проекты добавят ссылку на эти файлы сборки.Я предполагаю, что ваши пользовательские сборки Framework будут иметь то же имя, что и обычные сборки Framework, так что вы можете легко заменить эти файлы по мере необходимости (или создать отдельные ветки ваших проектов, использующих пользовательскую Framework).

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

1 голос
/ 05 марта 2012

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

Я бы положил первые рамки ddl в GAC из-за вышеизложенного.

Я бы поместил второй фреймворк в спроектированную папку под вашей TFS, называемой экземпляром «Библиотека», куда вы добавите ссылку (Вся ваша команда должна иметь одинаковую структуру папок, чтобы избежать пропусков ссылок)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...