Nant: Как структурировать svn:externals для создания библиотек классов, которые ссылаются на сторонние библиотеки DLL

Я использую Subversion и Nant (и Visual Studio IDE)

Я следовал предложенной структуре проекта по адресу http://blog.jpboodhoo.com/NAntStarterSeries.aspx которая защищает автономные каталоги Subversion, где разработчик может сделать извлечение и сразу создать проект за один шаг.

Моя структура репо выглядит так:

/Repo
  /MainProject
    /trunk
      /doc   <-- documentation
      /lib   <-- binary-only DLLs
      /src   <-- source code for MainProject
      /tools <-- holds tools like nant, nunit, etc
...
  /ClassLibrary1
    /trunk
      /doc
      /lib
      /src
      /tools
...
  /ClassLibrary2
    /trunk
      /doc
      /lib
      /src
      /tools

Что не ясно, так это как структурировать проект, который имеет библиотеки классов, которые в свою очередь ссылаются на сторонние библиотеки dll.

В настоящее время у меня есть основной проект с рабочим каталогом, как

Пример:

/MainProject
  /build
  /lib
  /src
    /MainProject
    /ClassLibrary1 <-- svn external to svn://server/repo/ClassLibrary1/trunk/src
    /ClassLibrary2 <-- svn external to svn://server/repo/ClassLibrary2/trunk/src
  /tools
  ...

При сборке MainProject я компилирую библиотеки классов и выводю dll в папку build. Однако сами библиотеки классов имеют сторонние DLL-файлы, на которые они ссылаются.

Мои вопросы для того, чтобы построить MainProject, мне нужно каким-то образом получить сторонние DLL из библиотек классов в выходные данные сборки. Как я могу это сделать?

Мысли: 1. Должен ли я хранить копии этих сторонних dll в папке lib MainProject? 2. Или моя ссылка svn:external должна быть на ствол проекта библиотеки классов, а не на src, чтобы я мог получить доступ к папке lib библиотеки классов? 3. Должен ли я использовать функцию Subversion 1.6 в svn:externals для отдельных файлов?

Источник

3 ответа

Решение

Лично я привожу в багажнике упомянутые библиотеки. (На самом деле, я ввожу корень тега, но это не относится к делу).

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

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

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

Источник

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

  2. Или моя ссылка svn:external должна быть на ствол проекта библиотеки классов, а не на src, чтобы я мог получить доступ к папке lib библиотеки классов? Я не предпочитаю такой подход, так как он делает процесс создания нового разработчика более запутанным. Я думаю, что сборка может войти в свой собственный репозиторий, когда она имеет уровень важности для себя. Но я бы никогда не сослался на его вывод. Он должен иметь процесс сборки, обернутый вокруг него, который продвигает механизм для "развертывания" вывода в вышеупомянутый каталог ссылок или зависимостей. Однако автоматизация такого развертывания может быть сопряжена с проблемами. Было бы лучше, если бы у сборки был собственный процесс. И когда была выпущена новая версия сборки, она была бы вручную включена разработчиком в проект, который нуждался в этом. Затем они могли бы проверить его, принять его и поместить в процесс сборки. Очевидно, что если эта сборка меняется ежедневно, может потребоваться некоторая автоматизация.

  3. Должен ли я использовать функцию Subversion 1.6 в svn:externals для отдельных файлов? Нет. Я предпочитаю сохранять проект / решение как отдельную сущность. Распространение палаток по всему месту делает зависимости более болезненными. Сохраняйте бункеры как можно более жесткими... вносите новые вещи как можно более ручными... или настолько ручными, насколько это возможно с той частотой, с которой они меняются.

Источник

У меня была похожая потребность, и я нашел краткий ответ в документации TortoiseSVN:

http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-howto-common-projects.html

Источник
Другие вопросы по тегам