Как правильно включать общие библиотеки в несколько проектов (для целей CI) - PullRequest
Новая
       36

Как правильно включать общие библиотеки в несколько проектов (для целей CI)

1 голос
/ 23 марта 2011

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

  • [Название решения]
    • документация (документация)
    • extlib (внешние библиотеки зависят от нескольких исходных проектов)
      • [Nunit]
      • [FluentValidation]
      • и т.д.
    • src (исходный код)
      • Файл решения
      • [Папка проекта библиотеки C #]
      • [Папка проекта MVC 3]
      • [Папка тестового проекта NUnit]

У меня есть процесс сборки в CruiseControl .NET для каждого проекта. Однако, например, когда я включаю FluentValidation в свой библиотечный проект из его местоположения вне «extlib», CruiseControl не знает об этом каталоге и выдает ошибку.

Я хотел сохранить всю свою внешнюю библиотеку в одном месте (одинаковые версии и т. Д.), Но действительно ли это необходимо?

Могу поспорить, что есть лучший способ сделать это (возможно, пакеты NuGet?) Какова альтернатива наилучшей практики для того, как я пытался настроить мой процесс сборки здесь?

Обновление: К вашему сведению, я знаю, почему вызвана ошибка. Это вызвано тем, что папка extlib находится над моими исходными проектами, но я собираю исходные проекты только в их папках артефактов для сборки. Итак, чтобы пересмотреть вопрос, мне интересно, будет ли это лучший способ перенастроить все мои настройки CruiseControl или будет лучше использовать пакеты NuGet в каждом проекте и т. Д.

Заранее благодарим за любую помощь, которую вы можете оказать!

- Шон

Ответы [ 3 ]

1 голос
/ 23 марта 2011

Для CruiseControl.NET более естественно работать на уровне решения.Я бы предложил проверить весь ваш репозиторий и использовать разные триггеры для каждого проекта (как вы указали в своем собственном комментарии:)).

1 голос
/ 23 марта 2011

У меня такая же ситуация на работе.Раньше у нас было единственное сетевое место, куда мы помещали все третьи библиотеки, используемые нашим проектом, и выходные данные наших проектов dll (наборы инструментов, ведение журнала и т. Д.).

Что мы сделали, так это ECI (EnterpriseНепрерывная интеграция).Вы можете прочитать об этом здесь .Мы обсуждали это в списке рассылки ccnet-user, тема: здесь .

По сути, ваши extlibs - это ваша папка управления исходным кодом, и инструмент CI обновляет их автоматически после внесения изменений.и проверено (например, модульными тестами).

Плюсы:

  • Вы можете вносить изменения в свои базовые блоки, не тестируя эффекты для каждого проекта, который зависит от него,cc.net подтвердит это для вас.
  • Вы можете продолжать разработку больших проектов, и даже если более новая версия вашего маленького кирпича (временно) несовместима

Недостатки:

  • Увеличение размера репозитория управления исходным кодом
  • ???

Что касается отзывов, некоторым разработчикам нужно время, чтобы понять процесс, но все онигораздо счастливее с новой системой, они могут зафиксировать изменения и в течение нескольких минут увидеть, сломали ли они другой проект или нет.Их развертывание теперь намного спокойнее!

РЕДАКТИРОВАТЬ:

Извините, я неправильно понял ваш вопрос, но мой отзыв все еще полезен.Почему бы вам не проверить файлы на узле «Имя решения» вместо src?

0 голосов
/ 23 марта 2011

CCNET не должна знать о внешней библиотеке, поскольку ссылка на внешнюю библиотеку будет в каждом отдельном файле .CSPROJ.Не могли бы вы убедиться ниже вещей

  • Убедитесь, что папка extlib существует в ожидаемом месте

  • Убедитесь, что все проекты ссылаются на внешние DLLимеет правильные записи в ExtLIB в файле .CSPROJ (вы можете отредактировать и проверить это).

...