Для MSVC, под виндами, С#, winforms, если что.
Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.
Понятно что абсолютно однозначного ответа нет, зависит от конкретной ситуации. Допустим, когда исходники стабильные и практически не меняются, либо от кого-то другого, то видимо DLL-ки с PDB (и отдельными исходниками для отладки) лучше. По крайней мере, нет никакой возможности изменить непреднамеренно код.
Речь же идет исключительно об исходниках текущего проекта, собираемого из многих подпроектов. Просто часто сталкивался, когда исходники чуть чуть отличаются от ДЛЛ-ки и фиг поймешь отчего вдруг не работает/вылетает. Хотя некоторые имеют мнение, что при наличии решарпера и многих разработчиков лучше пользовать исключительно ДЛЛ-ки, несмотря на наличие в солюшин всех требуемы подпроектов с исходниками. А то что кто то забудет актуальную версию загрузить, нужно регулировать постановлениями партии и правительства
Хотелось бы услышать различные мнения за и против каждого из подходов, чтобы не ругатся до состояния "пены у рта".
ИМХО чаще подключается DLL. Навскидку приходят такие минусы подключения исходников стороннего проекта:
— Скорее всего исходников подключаемого проекта не окажется в репозитории, что может оказаться проблемой при checkout'е на другом/чистом компьютере
— Если хранить подключаемые проекты в репозитории, то это увеличивает размер репозитория (а необходимость подключения стороннего проекта через исходники может быть сомнительна)
— Увеличится время компиляции проекта
— Возможно, что нужна стабильная версия подключаемого проекта. Допустим, я в своем проекте А использую проект Васи — Б (может и сам в нем тоже участвую), проект Васи Б тоже под контролем версий у меня. Тогда, если вдруг Вася что-то изменит в проекте Б, а я сделаю update проекта Б, то в моем проекте А может что-то поломаться или придется что-то менять.
Здравствуйте, AlexNek, Вы писали:
AN>Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.
В разных случаях нужно по-разному.
Расскажу, как можно подключать через исходники на примере использования Mercurial. Для этого создаются репозитории-модули с исходниками/ассетами и один или несколько тонких мастер-репозиториев, содержащих только sln-файлы, файл .hgsub со списком модулей-субрепозиториев и .hgsubstate с информацией о чейнджсетах субрепозиториев, ассоциированных с текущим состоянием мастер-репозитория.
Скажем, у тебя есть проект MyProduct.Core, который используется твоим проектом MyProduct.Client и проектом MyProduct.Server, над которым независимо работают коллеги. Создаёшь два мастера:
Если кто-то, работая над сервером, внесёт изменения в MyProduct.Core (скажем, обновит его до версии 3.5.0.128), то у тебя в клиенте ничего не сломается, потому что мастер-репозиторий для клиента всё ещё нацелен на предыдущий рабочий чейнджсет подпроекта MyProduct.Core (скажем, 3.4.0.125). Можешь продолжать работать со своей версией. Видя что в субрепозиторий пришли новые чейнджсеты, в удобное для себя время можешь обновить рабочую папку до актуальной версии и восстановить работоспособность своего клиента.
Относительно другого косвенно затронутого вопроса. По dll'кам всегда должна быть возможность восстановить идентификатор чейнджсета или хотя бы номер ревизии исходников, из которых библиотека была собрана. Первое можно вшить в dll'ку кастомным атрибутом, второе — прямо в последний компонент версии (см. стандартные атрибуты AssemblyVersion, AssemblyFileVersion, AssemblyInformationalVersion).
Глаза у меня добрые, но рубашка — смирительная!
Re: Как лучше подключать подпроекты - DLL или исходники чере
Здравствуйте, AlexNek, Вы писали:
AN>Речь же идет исключительно об исходниках текущего проекта, собираемого из многих подпроектов. Просто часто сталкивался, когда исходники чуть чуть отличаются от ДЛЛ-ки и фиг поймешь отчего вдруг не работает/вылетает. Хотя некоторые имеют мнение, что при наличии решарпера и многих разработчиков лучше пользовать исключительно ДЛЛ-ки, несмотря на наличие в солюшин всех требуемы подпроектов с исходниками. А то что кто то забудет актуальную версию загрузить, нужно регулировать постановлениями партии и правительства AN>Хотелось бы услышать различные мнения за и против каждого из подходов, чтобы не ругатся до состояния "пены у рта".
Если это подпроекты одного большого проекта, и все исходники в солюшене — однозначно не стоит делать никаких ссылок на бинарники. Никакой пользы это не несет, кроме незначительного ускорения компиляции.
Зато факт, что используемый реально код не соответствует исходникам вызывает бешенную ненависть после кучи времени потраченного на детект ситауции. А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?
Здравствуйте, Qbit86, Вы писали:
Q>В разных случаях нужно по-разному.
Ещё рассмотри вариант создавать бинарные NuGet-пакеты, заливаемые на доступный всем разработчикам источник. Все работают со своими (строго определёнными) версиями бинарников, и могут при желании проапдейтится со стабильных до текущих версий. Потом поделись опытом, плюсы, минусы, подводные грабли.
Сам по себе пакетный менеджер NuGet для общеизвестных библиотек очень удобная штука, не нарадуюсь.
Глаза у меня добрые, но рубашка — смирительная!
Re: Как лучше подключать подпроекты - DLL или исходники чере
Здравствуйте, AlexNek, Вы писали:
AN>Для MSVC, под виндами, С#, winforms, если что. AN>Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.
ИМХО, однозначно только использовать подключение библиотек.
Назовем ради примера:
общая часть — сервер,
пользователи общей части — клиенты.
Минус только один — увеличивается время внесения изменений в сервер и процесс уведомления клиентов, чтобы они заюзали обновленную версию сервера
(это даже еще не означает что они должны немедленно использовать обновление).
Плюсы:
Возможность внесения любых изменений в сервер за фиксированное время, без рисков что эти изменения поломают какого-то клиента
Версионирование сервера — возможность для разных клиентов юзать разные версии сервера
Время на внесение изменений в клиент с использованием стабильной версии сервера всегда фиксированно и не имеет рисков из-за сервера
Возможность быстрой замены новой версии сервера, в которой вдруг возникла неожиданная критическая ошибка, на старую и проверенную версию
сервера для конечного пользователя — этот пункт самый важный, поскольку деньги на разработкудают именно конечные пользователи всей системы).
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>ИМХО, однозначно только использовать подключение библиотек.
хъ
Это все прекрасно делается с нормальными системами контроля версий
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>Минус только один
Минус не только один. Среди прочих:
К задаче версионирования и публикации исходников добавляется задача версионирования и доставки разработчикам производных артефактов.
Проще отлаживать, когда исходники рядышком.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, MozgC, Вы писали:
MC>ИМХО чаще подключается DLL.
Я лично сталкивался чаще с обратным, причем часто вначале подключали Длл-ки, а после затыкав переходили на проекты. MC>Навскидку приходят такие минусы подключения исходников стороннего проекта: MC>- Скорее всего исходников подключаемого проекта не окажется в репозитории, что может оказаться проблемой при checkout'е на другом/чистом компьютере
В обсуждаемом варианте они всегда есть. MC>- Если хранить подключаемые проекты в репозитории, то это увеличивает размер репозитория (а необходимость подключения стороннего проекта через исходники может быть сомнительна)
размер бинарниками будет несравненно больше, вес проекты "свои". MC>- Увеличится время компиляции проекта
Только первый раз, да и нет сотни гигантских подпроектов. MC>- Возможно, что нужна стабильная версия подключаемого проекта. Допустим, я в своем проекте А использую проект Васи — Б (может и сам в нем тоже участвую), проект Васи Б тоже под контролем версий у меня. Тогда, если вдруг Вася что-то изменит в проекте Б, а я сделаю update проекта Б, то в моем проекте А может что-то поломаться или придется что-то менять.
Вообще то это и нужно как можно раньше определить. Или иначе, нельзя тогда вообще иметь исходников других продключаемых проектов.
Если исходники Васи все же пользуются, а они не будут совпадать с Длл-ков, то последствия могут быть непредсказуемыми.
А несовпадение довольно просто. Или мы забыли взять последнюю версию всего или Вася забыл обновить библиотеку или обновил не на последнюю версию.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, AlexNek, Вы писали:
AN>>Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.
Q>В разных случаях нужно по-разному.
Да — это понятно. Хотелось бы иметь что то типа рекомендаций/статистики по часто используемым случаям. Мои аргументы уже все исчерпались.
Q>Расскажу, как можно подключать через исходники на примере использования Mercurial.
Есть только SVN.
Q>Относительно другого косвенно затронутого вопроса. По dll'кам всегда должна быть возможность восстановить идентификатор чейнджсета или хотя бы номер ревизии исходников, из которых библиотека была собрана. Первое можно вшить в dll'ку кастомным атрибутом, второе — прямо в последний компонент версии (см. стандартные атрибуты AssemblyVersion, AssemblyFileVersion, AssemblyInformationalVersion).
Во время разработки обычно никто после изменения пары строчек не меняет номер версии. Это прерогатива "выпускающего"
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, AlexNek, Вы писали:
AN>>Речь же идет исключительно об исходниках текущего проекта, собираемого из многих подпроектов. Просто часто сталкивался, когда исходники чуть чуть отличаются от ДЛЛ-ки и фиг поймешь отчего вдруг не работает/вылетает. Хотя некоторые имеют мнение, что при наличии решарпера и многих разработчиков лучше пользовать исключительно ДЛЛ-ки, несмотря на наличие в солюшин всех требуемы подпроектов с исходниками. А то что кто то забудет актуальную версию загрузить, нужно регулировать постановлениями партии и правительства AN>>Хотелось бы услышать различные мнения за и против каждого из подходов, чтобы не ругатся до состояния "пены у рта".
Z>Если это подпроекты одного большого проекта, и все исходники в солюшене — однозначно не стоит делать никаких ссылок на бинарники. Никакой пользы это не несет, кроме незначительного ускорения компиляции.
К сожалению это на аргумент в споре не тянет Меня интересуют прежде всего аргументы, которые возможно я забыл/не заметил.
Z>Зато факт, что используемый реально код не соответствует исходникам вызывает бешенную ненависть после кучи времени потраченного на детект ситауции.
На это отвечают — прищучим всех Во что слабо верится. Z>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?
Аргументируют, что Длл-ку имеет право изменить только "автор". А при наличии исходников, кто угодно. В результате локальная версия может не совпадать с конечной.
Хотя если все билдится из репозитория, то это уже относительно простая проблема разработчика не иметь изменений в "чужих" проектах. При чекине видно на раз.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Qbit86, Вы писали:
Q>>В разных случаях нужно по-разному.
Q>Ещё рассмотри вариант создавать бинарные NuGet-пакеты, заливаемые на доступный всем разработчикам источник. Все работают со своими (строго определёнными) версиями бинарников, и могут при желании проапдейтится со стабильных до текущих версий. Потом поделись опытом, плюсы, минусы, подводные грабли.
Кто будет их создавать и когда? А также когда их брать? А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.
Допустим в 16:00 создали либы по репозиторию, а в 16:15 кто то залил изменения в репозиторий. В итоге те кто возьмут пакет и обновление репозитория в 16:20 получат несоответсвие.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>Плюсы:
Q>Перечисленных плюсов можно добиться и ссылаясь на исходники.
Пример:
Нужно внести в клиент срочные минорные изменения.
Естимейты — 1 день с рисками и тестами.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>ИМХО, однозначно только использовать подключение библиотек. WH>хъ WH>Это все прекрасно делается с нормальными системами контроля версий
Здравствуйте, AlexNek, Вы писали:
Q>>Расскажу, как можно подключать через исходники на примере использования Mercurial. AN>Есть только SVN.
Можно пристально посмотреть в сторону svn:externals. И вообще, повлиять на руководство в сторону приобщения к правильным и удобным инструментам.
AN>Во время разработки обычно никто после изменения пары строчек не меняет номер версии. Это прерогатива "выпускающего"
Версии (major, minor, maintenance) — да. А номер build'а (у нас это номер ревизии того локального клона репозитория, с которого идёт сборка на билд-сервере; нужна только для удобства) и атрибут с чейнджсетом (скажем, 111c07b94e72, для уникальной идентификации) — добавляются автоматически. Т.е. поддержания обратного маппинга (от бинарника dll'ки к версии исходников) происходит без участия человеков типа «выпускающего».
Когда угодно. У тебя стоит ссылка на пакет версии 3.4.0.128. То, что на билд-сервере появляются версии 3.4.0.129, 3.4.0.130, etc твою программу не ломает. То же, что и со сторонними библиотеками. Скажем, используешь ты NUnit 2.5.9.10348. То, что вышла новая версия NUnit 2.5.10.11092 никоим образом на твою программу повлиять не может, пока ты сам не решишь обновиться.
AN>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.
Не понял вопрос. Твоя переиспользуемая библиотека теперь выглядит так же, как не твоя переиспользуемая библиотека. От которой у тебя нет, и не нужны исходники. Все проекты всегда ссылаются на точную версию строгоименованной библиотеки.
AN>Допустим в 16:00 создали либы по репозиторию, а в 16:15 кто то залил изменения в репозиторий. В итоге те кто возьмут пакет и обновление репозитория в 16:20 получат несоответсвие.
Нет, они продолжают использовать пакет от 16:00. Всё собирается, работает. Но могут нажать кнопку Update Packages, когда готовы начать разрешать потенциально появившиеся конфликты из-за отсутствия обратной совместимости версий разрабатываемой переиспользуемой библиотеки.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>Здравствуйте, AlexNek, Вы писали:
AN>>Для MSVC, под виндами, С#, winforms, если что. AN>>Временами на работе возникают дискуссии, что подключать лучше в солюшин как внешние ссылки при наличии исходников — DLL-ки или проекты.
A_A>ИМХО, однозначно только использовать подключение библиотек. A_A>Назовем ради примера: A_A>общая часть — сервер, A_A>пользователи общей части — клиенты.
То есть пример практически не связанного кода. Максимум — протоколы обмена, видимо.
А что если класс Б наследуется от А и они в разным проектах?
A_A>Минус только один — увеличивается время внесения изменений в сервер и процесс уведомления клиентов, чтобы они заюзали обновленную версию сервера
То бишь сервер не у разработчика локально?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>ИМХО, однозначно только использовать подключение библиотек. WH>хъ WH>Это все прекрасно делается с нормальными системами контроля версий
. WH>Поставь git или hg и будет тебе счастье.
Увы, но система контроля версий не может менятся локально для команды. Многие процессы уже завязаны на конкретную систему.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>Минус только один
Q>Минус не только один. Среди прочих: Q> К задаче версионирования и публикации исходников добавляется задача версионирования и доставки разработчикам производных артефактов. Q> Проще отлаживать, когда исходники рядышком.
Да это мне тоже нравится, но с PDB вроде не должно быть отличий, исходники проекта и так всегда есть в наличии ( по крайней мере это одно из условий задачи).
Отличие только в том, что происходит при связывании подпроектов.
