2012-03-05 6 views
7

У меня есть два сценария:Как я могу ссылаться на сборки из другого решения?

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

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

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

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

+0

Хотя это может быть не может быть ценными для вашей ситуации, если вы используете подрывной, СВНЫ: внешние были бы довольно простым решением эта ситуация. – Candide

ответ

4

Пользовательские рамки

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

Shared Framework

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

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

5

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

1

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

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

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

1

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

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

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

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

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

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

3

Звучит для меня классическая ссылка на проект и двоичное решение для принятия решений. Оставьте 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] 

Смежные вопросы