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

Question

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

2

Я использую subversion и nant (и visual studio IDE)

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

Моя структура репо выглядит следующим образом:

/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 в папку сборки. Тем не менее, сами библиотеки классов имеют стороннюю двоичную библиотеку DLL, которую они ссылаются.

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

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

User 14 авг. 2009, в 01:08

Источник

Теги:

c#

svn

class-library

nant

3 ответа

1

Должен ли я хранить копии этих сторонних библиотек DLL в папке MainProject lib? Я предпочитаю хранить любые внешние библиотеки в каталоге двоичных файлов под соединительной линии, но рядом с исходным кодом... или звонить это ссылки, зависимости и т.д. Затем это позволяет любому разработчику получить последние, и все, что потребуется, спустится. Это не обязательно должно быть частью проекта как такового. Он просто должен быть доступен, когда выполняется сборка.
Или должна ли моя svn: внешняя ссылка быть в trunk проекта библиотеки классов, а не в src, чтобы я мог получить доступ к папке lib библиотеки классов? Я не предпочитаю этого поскольку он делает процесс получения нового разработчика более запутанным. Я думаю, что сборка может войти в свой собственный репозиторий, когда он имеет уровень важности для себя. Но я никогда не буду ссылаться на его результаты. Он должен иметь процесс сборки, обернутый вокруг него, который продвигает механизм "развертывания" вывода в вышеупомянутый каталог ссылок или зависимостей. Однако автоматизация такого развертывания может быть сопряжена с проблемами. Было бы лучше, если бы на собрании был свой собственный процесс. И когда была выпущена новая версия сборки, она была бы объявлена разработчиком в проекте, который в ней нуждался. Затем они могут проверить это, принять его и поместить в свой процесс сборки. Очевидно, что если эта сборка меняется ежедневно, может потребоваться автоматизация.
Должен ли я использовать функцию subversion 1.6 для svn: externals для отдельных файлов? Нет. Я предпочитаю сохранить проект/решение как автономную сущность. Распространение школьных материалов на все места делает зависимости более болезненными. Держите силосы как можно труднее... привносите новые вещи в максимально возможной степени... или как руководство, так как частота, с которой могут измениться вещи, позволит.

Andrew Siemer 13 авг. 2009, в 20:28

0

Я думаю, суть проблемы в том, что проект библиотеки классов имеет ссылку на стороннюю DLL. Эта DLL хранится в папке lib библиотеки классов (которая предназначена для хранения сторонних двоичных DLL-библиотек) в ClassLibrary1 / trunk / lib. Однако MainProject должен каким-то образом ссылаться на стороннюю DLL для своей сборки. Как мне это сделать?
User 13 авг. 2009, в 22:39
0

Итак, мой вопрос заключается в следующем. Вы говорите, что библиотека классов зависит от этого стороннего виджета и хранит его в папке lib для этого проекта. И проблема в том, что ваш проект также зависит от этого стороннего виджета ... почему бы не сохранить его в локальной папке lib?
Andrew Siemer 14 авг. 2009, в 00:43
0

Вы имеете в виду локальную папку lib для основного проекта или локальную папку lib для проекта Class Library? Если вы имеете в виду последнее, то мне нужно иметь svn: externals для ствола библиотеки классов (это мой вопрос № 2 выше) Не то, чтобы основной проект имел прямую зависимость от виджета, это то, что проект имеет зависимость от библиотеки классов. Библиотека классов, в свою очередь, имеет свои собственные зависимости (т.е. библиотека классов не будет работать без доступа к сторонним DLL)
User 14 авг. 2009, в 16:34

Показать ещё 1 комментарий

0

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

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

Julien Bérubé 01 дек. 2010, в 16:04

Ещё вопросы

Я думаю, суть проблемы в том, что проект библиотеки классов имеет ссылку на стороннюю DLL. Эта DLL хранится в папке lib библиотеки классов (которая предназначена для хранения сторонних двоичных DLL-библиотек) в ClassLibrary1 / trunk / lib. Однако MainProject должен каким-то образом ссылаться на стороннюю DLL для своей сборки. Как мне это сделать?
Итак, мой вопрос заключается в следующем. Вы говорите, что библиотека классов зависит от этого стороннего виджета и хранит его в папке lib для этого проекта. И проблема в том, что ваш проект также зависит от этого стороннего виджета ... почему бы не сохранить его в локальной папке lib?
Вы имеете в виду локальную папку lib для основного проекта или локальную папку lib для проекта Class Library? Если вы имеете в виду последнее, то мне нужно иметь svn: externals для ствола библиотеки классов (это мой вопрос № 2 выше) Не то, чтобы основной проект имел прямую зависимость от виджета, это то, что проект имеет зависимость от библиотеки классов. Библиотека классов, в свою очередь, имеет свои собственные зависимости (т.е. библиотека классов не будет работать без доступа к сторонним DLL)

Jim T · Accepted Answer · 2009-08-14T05-15-00.000Z

1

Лучший ответ

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

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

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

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

Jim T 14 авг. 2009, в 05:15

0

«Если вы сохраняете отдельную копию требуемых библиотек DLL, значит, вы не позволяете указанной библиотеке определять, что ей нужно для себя». Это имеет смысл. Я предполагаю, что мое сопротивление этому заключается в проверке «лишних» папок библиотеки. Тем более, что я храню инструменты в библиотеке. Если основной проект ссылается на 10 библиотек классов, то у меня будет 10 копий nant, библиотеки создают сценарии и т. Д. Но, может быть, это случай беспокойства о дисковом пространстве, когда в этом нет необходимости?
User 14 авг. 2009, в 16:25
0

Чем больше я думаю об этом, тем более ясным решением кажется использование библиотеки как svn: external. Я просто хотел узнать, как это делают другие.
User 14 авг. 2009, в 23:38
0

Я поместил свое свойство svn: externals, чтобы получить библиотеки классов в папке src MainProject. Это имело смысл, когда я брал только каталог trunk / src библиотек классов. Однако, если я переключаюсь на захват ствола библиотеки классов, мне интересно, имеет ли смысл перенести это в каталог src. В какой каталог вы помещаете свойство externals?
User 16 авг. 2009, в 23:53
0

Это не очень важно, где, только если это согласованно :) Я бы предложил самый высокий уровень, на котором вы постоянно проверяете ветку, поэтому, если вы все время проверяете ствол, поместите их в ствол. Если вы заказываете src, поместите их на src. Я фактически создаю папку внутри src под названием externals и помещаю ее туда. Он работает нормально, и так как у меня есть папка с именем «build», я могу поместить туда разные внешние элементы (т.е. nant). Но что бы вы ни делали, старайтесь не размещать внешние элементы на разных уровнях, если вам нужно покопаться, чтобы обновить ссылки, это настоящая боль. Мучительные вещи не заканчиваются.
Jim T 17 авг. 2009, в 06:31
0

У меня есть проект, в котором MainProject использует несколько ClassLibraries и как MainProject, так и ClassLibraries используют CommonClassLibrary. Так что есть своего рода вложенная структура. В этом случае вы помещаете svn: externals в ClassLibraries для добавления CommonClassLibrary? Если MainProject использует 5 библиотек классов, это означает, что CommonClassLibrary будет повторяться 5 раз как подкаталоги. Как бы вы справились с этой ситуацией?
User 22 авг. 2009, в 02:24
0

Вложение может определенно стать болью, но я бы не стал зацикливаться на этом, если только это не станет причиной проблем. Если это вызывает проблемы, пришло время приступить к упорядочению, чтобы проблемные библиотеки больше не вкладывались - вместо этого вытащите подмножество транков и убедитесь, что проект получает общую библиотеку в отдельной внешней ссылке. Другая возможность состоит в том, чтобы вместо этого начать извлекать предварительно скомпилированные двоичные файлы (возможно, из отдельного репозитория, файлового ресурса и т. Д.), Что я рассматривал в прошлом.
Jim T 26 авг. 2009, в 11:38

Показать ещё 4 комментария