Блог

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

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

Например: все наши ветви сопоставлены с «C:Code «. Таким образом, магистраль будет «C:CodeTrunk «и ветка была бы «C:Codesomebranch «.

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

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

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

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

Подводя итог всему этому:

• Как добавить ссылку, относящуюся к решению? (т.е. Добавить ссылку на C:CodeTrunkAssembliessomeassembly .dll и пусть этот путь будет относительным к проекту, который его добавил, чтобы при создании ветки он ссылался на папку разветвленных сборок, а не на папку сборок магистрали. Или эта ссылка уже относительна?

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

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

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

таким образом, каждая ветвь (и магистраль) будет хранить их версию.

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

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

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

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

Да, путь уже является относительным. При разветвлении ваши проекты получат правильную папку assemblies.

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

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

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

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

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

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