Где хранить сторонние сборки?

Question

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

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

Например: все наши ветви отображаются в "C: \ Code \". Таким образом, транк будет "C: \ Code \ Trunk", а ветвь будет "C: \ Code \ somebranch".

Если я создаю папку в «C: \ Code \ Trunk» под названием «Сборки», а затем отбрасываю все наши сторонние сборки в эту папку, а затем добавляю ссылку на сборку, есть ли относительная ссылка на сборку? Если щелкнуть добавленную сборку, я вижу, что свойство пути, выделенное серым цветом, говорит «C: \ Code \ Trunk \ Assemblies \ someassembly.dll».

Что произойдет, если я потом разветвлюсь из ствола? Будет ли «somebranch» по-прежнему иметь ссылку на «C: \ Code \ Trunk \ Assemblies \ someassembly.dll» или тогда будет ссылка «C: \ Code \ somebranch \ Assemblies \ someassembly.dll»?

В настоящее время у нас фактически есть ветвь в управлении исходным кодом, называемая "Сборки", которая, как и любая другая ветвь, отображается в "C: \ Code \". Поэтому все ветви с проектами, ссылающимися на сборки, имеют ссылки на «C: \ Code \ Assemblies \ someassembly.dll», независимо от того, в какой ветви находится проект, путь будет одинаковым.

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

Подводя итог:

• Как добавить ссылку относительно решения? (т. е. добавьте ссылку на C: \ Code \ Trunk \ Assemblies \ someassembly.dll и укажите этот путь относительно проекта, который его добавил, чтобы при создании ветви он ссылался на папку с разветвленными сборками, а не на папку сборок в стволе. Или эта ссылка уже относительная?

• Каковы другие рекомендуемые стратегии для управления сторонними сборками?

Answer 1

Теперь у нас есть nuget , вы можете использовать его для всех поддерживаемых пакетов oss и даже создавать свои собственные пакеты nuget для других сторонних сборок. Стоит упомянуть openwrap в качестве альтернативы nuget.

Nuget хранит пакеты на уровне решения

чтобы каждая ветвь (и ствол) сохраняли свою версию.

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

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

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

Answer 2

Да, используйте папку сборок вне транка. Мне нравится имя lib лучше, чем сборки.

Да, путь уже относительный. При ветвлении ваши проекты получат правильную папку сборок.

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

Answer 3

В нашем решении есть папка SolutionItems для сторонних ссылок.Каждая ветвь решения имеет свою собственную копию.

Когда мы добавляем ссылку, мы используем вкладку «Обзор» в диалоговом окне добавления ссылки и выбираем сборку относительно нашего текущего проекта.

Файл проекта содержит это:

<Reference Include="SomeAssembly, Version=0.1.0.0, Culture=neutral, PublicKeyToken=8xxxxxxxxxxx, processorArchitecture=MSIL">
    <SpecificVersion>False</SpecificVersion>
    <HintPath>..\Solution Items\SomeAssembly.dll</HintPath>
</Reference>

Answer 4

Я обычно создаю общий проект, на который ссылаются все остальные.Внутри этого общего проекта я создаю папку с именем deps (для зависимостей).Каждый из других проектов затем ссылается на копию DLL в общей папке проекта deps.