Работа с общими / служебными библиотеками

Question

В компании, в которой я работаю, у нас есть проект «Утилита», на который ссылается практически любое приложение, которое мы создаем. У него есть много вещей, таких как NullHelpers, ConfigSettingHelpers, Common ExtensionMethods и т. Д.

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

Это сработало нормально, однако была пара случаев, когда люди вносили «критические изменения» в общий проект, который работает для них, но не работает для других.

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

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

Answer 1

Это именно то, что мы делаем. У нас есть служебный проект, который имеет некоторые не связанные с проектом полезные функции. Мы увеличиваем версию вручную (второстепенно), собираем проект в версии Release, подписываем его и помещаем в общую папку.

Люди тогда используют конкретную версию библиотеки .

Если в некоторых конкретных проектах реализованы некоторые полезные методы, которые могут попасть в основной проект Utility, мы помещаем их в специальный вспомогательный класс в проекте и помечаем их как возможного кандидата Utility (простой // TODO). В конце проекта мы проверяем кандидатов и, если они придерживаются, мы перемещаем их в основную библиотеку .

Срочные изменения запрещены, и мы помечаем методы и классы как [устаревшие], если это необходимо.

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

Надеюсь, это поможет.

Answer 2

Мы используем ветвление в управлении исходным кодом; все используют головную ветку, пока не выпустят релиз. Когда они разветвляют релиз, они разветвляют и проект общих утилит.

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

Конечно, у нас все еще есть проблемы, о которых вы иногда упоминаете. Но когда одна команда регистрирует изменение, которое нарушает сборку другой команды, это обычно означает, что контракт для этого метода / объекта где-то нарушен. Мы рассматриваем это как возможность улучшить дизайн проекта общих утилит ... или, по крайней мере, написать больше юнит-тестов: /

Answer 3

У меня была EXACT такая же проблема!

Раньше я использовал ссылки на проекты, но все кажется плохим, когда, как вы говорите, на него ссылаются многие проекты.

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

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