Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>Здравствуйте, AlexNek, Вы писали:

A_A>>>>>Нужно собирать либу с такой версией, чтобы можно было найти реальные исходники.
AN>>>>Кто и как будет проверять версию Длл-ки при входе в функцию?
A_A>>>Тут поможет перегрузка функций, если уж совсем никак.
AN>>Примерчик мона?
A_A>Есть класс в длл-ке(который лезет в базу за данными), у которого паблик только дефолтный конструктор.
A_A>Его уже юзают кучка клиентов.
A_A>В новой версии для нового клиента понадобилось добавить в этот класс возможность повтора подключения к базе,
A_A>если она не доступна.
A_A>Перегружаешь конструктор и юзаешь новую версию в новом клиенте.
A_A>Все остальные клиенты юзают старую версию.
A_A>Делаешь техническую таску на новую итерацию — отрефакторить всех остальных клиентов на юзание новой версии длл-ки.

Видимо Вы не так поняли, что я имел в виду.
Допустим раньше параметр не проверялся на ноль, а теперь сделали. Но вылет все равно проиходит по нулю (Длл-ка не обновилась). Смотрим исходники все нормально, не может там такого быть.
Ну а все всегда не перекроешь.
AN>>>>>>>>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.

AN>>>>А как тогда работать разработчику Длл-ки? Причем один разработчик часто отвечает за более чем одну Длл-ку?
A_A>>>А в чем проблема-то?
A_A>>>Просто надо больше комунницировать, чтобы о таких изменениях все были в курсе.
AN>>А если было сказано об изменениях, но допустим забыли, что то сделать, что привело к "рассогласованию" исходников с бинарниками.
A_A>Автоматизация без участия человека не допустит рассогласования исходников с бинарниками.
Это будет только в том случае когда прогу также роботы писать будут, а за ними будут другие роботы наблюдать. А так можно почти всегда найти ситуации в которых механизм даст сбой.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, AlexNek, Вы писали:

Z>>>>>А оно вам надо? И зачем вообще тратить время на загрузки "актуальных версий"?
AN>>>>Аргументируют, что Длл-ку имеет право изменить только "автор". А при наличии исходников, кто угодно. В результате локальная версия может не совпадать с конечной.
ГВ>>>Странная аргументация, очень странная. Она допустима только при одном условии: если автор работает в другой компании. Если все "авторы" работают в одной конторе — исходники должны быть доступны всем.
AN>>Речь идет о непреднамеренном изменении, причем в уже протестированной части (и "закрытой") части. А исходники и так доступны всем при двух вариантах. Только при подключении Длл-ок нужно целенаправленно лезть в иходники, а при подключенных исходниках это может сделать и прога рефакторига.

ГВ>ИМХО, это означает, что надо следить за тем, как используется программа рефакторинга (я сейчас не помню, позволяет ли решарпер ограничить изменения только одним проектом в солюшене).
Случайно изменить исходники можно многими методами.

ГВ>Ещё тут высказывали мысль, что можно часть репозитория открывать только на чтение — можно попробовать поиграть с таким подходом.
Это же кто и как будет это все администрировать.
Пока вот всего один единственный проект разрешили редактировать только экслюзивно и то часто возникают проблемы

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, AlexNek, Вы писали:

AN>>>>Хотелось бы услышать различные мнения за и против каждого из подходов, чтобы не ругатся до состояния "пены у рта".

ГВ>>>Задача-максимум: иметь возможность полностью пересобрать все проекты на любой машине разработчика.
AN>>Вообще то это задача минимум. Точнее, собрать конечный проект на любой машине разработчика. А пересобрать все бывает часто просто невозможно из-за ограничений по лицензии. А если даже все проекты свои, все равно могут быть ограничения. Например, для сборки одной из частей требуется "подписывать" данные в ресурсах приватным ключем.

ГВ>А ключ только у доверенного? По-моему, это тоже слегка перебор.
Отчего? Знание ключа позволит менять конфигурацию системы как заблагорассудится и вся политика лизензирования полетит нафиг.
Видел ситуации, когда даже доступ к исходникам разработчик получал после письменного распоряжения начальства и с предварительной подписью доп. соглашения о неразглашении и пр.

ГВ>>>А если сборка всех ваших исходников укладывается в час-два (сторонние библиотеки сейчас не считаем), то уместно иметь полную копию всех исходных текстов.
AN>>Я бы сформулировал следующее. Если проект находится в конечном листе иерарахии проектов, то с целью экономии времени, лучше поключать Длл-ки.

ГВ>Да экономия времени-то не ахти какая большая, прямо скажем. Меня смущают в подключении только DLL возможные конфликты платформ (x86, x64, AnyCPU, etc.) и конфигураций (Debug, Release). Второе в меньшей степени, конечно.
Разработка проиходит на одной заранее определенной платформе.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, AlexNek, Вы писали:

AN>>К сожалению это на аргумент в споре не тянет Меня интересуют прежде всего аргументы, которые возможно я забыл/не заметил.

Z>Пользы нет, вред есть. Какие еще аргументы нужны?
Пользу можно не заметить, а вред преувеличивать.
Кстати, о каком варианте речь?

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, AlexNek, Вы писали:

AN>>Аргументируют, что Длл-ку имеет право изменить только "автор".

Z>Это проблема. А если автор в командировке или на больничном?
Слово "Автор" не зря было взято в кавычки. Можно сказать текущий отвественный(-ные) за модификацию данной части кода.

AN>>А при наличии исходников, кто угодно. В результате локальная версия может не совпадать с конечной.

Z>Что мешает разработчикам это сказать? Словами? Не правьте чужие библиотеки. Они обычно ребята умные, понимают.
Это и так всем известно. Речь идет о непреднамеренном изменении.

Z>А если вдруг надо на одну либу посадить двоих разработчиков, не успевает один, держит всю команду. Как они будут мерджить бинарную dll? Правки то они начнут вносить одновременно. Первый разработчик пофиксил баг А, второй баг Б. Каждый выложил новую версию.
Как говорили, автомат вначале распространит первое исправление, затем второе.

AN>>В результате локальная версия может не совпадать с конечной.

Z>Эта проблема рождена нездоровой практикой иметь локальную версию и конечную (что бы не означали эти термины).
Как сделать без локальной версии?
Загрузился набор Длл-ок теперь требуется делать исправление в одной из них. Вначале то правится нужно локально, то есть собирать ее из исходников. Значит все исходники должны точно соотвествовать всем Длл-кам. И видимо в 99% случаев это будет именно так.
Z>Версия должна быть одна и любая ревизия должна собираться ровно так же как она собиралась на машине разработчика который ее создал, прогнал тесты и подписался под комитом. Любые другие способы ведут к неиллюзорным граблям.

Z>Бинарные ссылки допустимы только для внешних, по отношению к проекту зависимостей.

Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>Здравствуйте, Геннадий Васильев, Вы писали:

A_A>Мы, собственно, всегда под AnyCPU в Release и собираем — зачем иначе?
Попробуйте установить прогу на 64 битную ось.

Здравствуйте, AlexNek, Вы писали:

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

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

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>>Здравствуйте, Геннадий Васильев, Вы писали:

A_A>>Мы, собственно, всегда под AnyCPU в Release и собираем — зачем иначе?
AN>Попробуйте установить прогу на 64 битную ось.
Так сервера на продакшене все 64-битные. Ничего не пересобирается.
Оно ж AnyCpu. В чем проблема?

Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>Мне здесь помогает документация

Документация неполна, в отличие от исходников. Свеженький пример — попробуй найти в документации что нибудь по поводу того, какие в ремоутинге хидеры проходят уже в реальный HTTP запрос или ответ, и по какому алгоритму отфильтровываются те, что туда не проходят. Или как в реквесте на сервере формируется хидер __Uri.

A_A>А вместо отладки по коду, который я не могу пофиксить в практических целях, я лучше найду другое решение и пойду пить пиво.

Просто тебе пока везло, и ты не сталкивался с неочевидным поведением или просто откровенными багами фреймворка.

AVK>>Это как посмотреть. Багу то тебе надо устранить, а не МС.
A_A>И каким образом ты пользуешься результатами устранения багов в исходниках .Net Framework?

Вариантов избежания ситуации много:
1) Понять, что ошибка таки была не в фреймворке.
2) Понять, как подобрать входные параметры, чтобы ошибочная ситуация не возникала
3) Понять, какой кусок фреймворка надо переписать, чтобы обойти ситуацию без исправлений фреймворка
4) Воспроизвести багу минимальным семплом, закинуть на коннект. Пнуть нужных людей в Редмонде, получить на руки хотфикс.

Здравствуйте, AlexNek, Вы писали:

AVK>>Что значит в одном месте? Есои репозиторий единый, для апдейта нужно нажать кнопку ровно один раз ровно в одном месте.
AN>Во первых, в репо не один проект.

Ну и что? Тебе места на диске жалко?

AN> Во вторых, в ветке проекта, не только исходники, но и все сопутствующее.

Не понял. И при чем тут это сопутствующее?

AN>В третьих, скорость.

Скорость чего?

AN> В четвертых, все слепо коммитить запрещено.

Ну так и не надо все слепо коммитить.

AN> Ну и в основном, работа происходит через плагин к студии.

И что?

AN> Если брать с роота обновления, то будет длиться довольно долгое время.

Да ну нафик. Долгое время это сколько? 1 минуту? 2?

AN>Но дело ведь не в чтении, но и в записи.

И что с ней не так?

Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>Всегда ясно видно, что в проекте есть ссылка на нестандартную(не из .NET Framework) либу. Все нестандартные либы качаются с помощью батника.

Зачем батники, чем MsBuild не устроил?

Здравствуйте, AlexNek, Вы писали:

AN>Глянул сегодня NuGet — плагин к 2010, уже значит не подходит.

Нет, то плагин для среды. Для сборки же проектов Студия, разумеется, не нужна (да и откуда ей взяться на билд-сервере). Есть консольная утилита, состоящая из одного файлика — nuget.exe. Его достаточно по крайней мере для всего.

Здравствуйте, AlexNek, Вы писали:

AN>Допустим раньше параметр не проверялся на ноль, а теперь сделали. Но вылет все равно проиходит по нулю (Длл-ка не обновилась). Смотрим исходники все нормально, AN>не может там такого быть.
AN>Ну а все всегда не перекроешь.
Это один из самых неприятных багов.
Если версия либы будет соответствовать версии ревизии коммита, то эта проблема уйдет.

A_A>>Автоматизация без участия человека не допустит рассогласования исходников с бинарниками.
AN>Это будет только в том случае когда прогу также роботы писать будут, а за ними будут другие роботы наблюдать. А так можно почти всегда найти ситуации в которых механизм даст сбой.
Давайте расскажу поподробнее за этот механизм.
При создании новой версии либы, разработчик делает билд на CI с таргетом "Deploy". Если этот проект не поддерживает такой таргет
(т.е. не Database project or Web project etc.) тогда мы получим фейл билда и узнаем сразу.
Если процесс версионирования NuGet настироен неправильно -> получим фейл билда и узнаем сразу.
Итак, билд прошел успешно.
Если мы укажем несуществующую версию либы(т.е. кот орой нет физически в фиде NuGet) -> получим фейл апдейта батника NuGet и узнаем чуть по-позже.
имхо, вероятность сбоя невелика.

Здравствуйте, AlexNek, Вы писали:

AN>Глянул сегодня NuGet — плагин к 2010, уже значит не подходит.
Этот плагин не нужен.
NuGet юзается как хранилище модулей.
Загружаешь в него через msbuild + CI.
Вытягиваешь — через батник + кастомные таски.
У нас так

Здравствуйте, AlexNek, Вы писали:

A_A>>Делаете пилотные проекты(лучше скопировать текущие самые сложные, с наибольшим количеством зависимостей) — на них играетесь
AN>Кто даст время, деньги, ресурсы?
Заказчик конечно.
А вот твоя задача — объяснить ему, что эти затраты для него окупятся Плюс он еще и заработает на этом в ближайшем будущем.
Насчет ближайшего будущего лучше поделикатней, конечно, без гарантий.
A_A>>Потом постепенно переводите текущие на новую систему.
A_A>>Риски всегда есть. Чтобы о них узнать заранее нужно проводить ресерч.
AN>Прототип можно и за час сделать, а вот уже довести его до ума и подкрутить все мелочи — это уже время.
A_A>>А по поводу переходить или нет — выписываешь в список плюсы и минусы существующей системы и новой(насколько возможно собрать информацию)
A_A>>и будет ясно.
AN>Можно долго и нудно все выписывать и подсчитывать, но вот как быть с неким правилом — "не трогай рабочую систему".
Оо, это самое вкусное.
На прошлой конторе заказчики были из Израиля — все решения о не то что переводе на что-то более удобное в разработке,
а о банальном рефакторинге в легаси-коде(который находится в активной разработке еще), проходили с жуткими боями в виде закидывания аргументами.
После замеров времени выполнения трех(самых веселых) методов сервисов бизнес-логики и выкладывания этого всего дела в виде красивых графиков,
моя рекомендация по переводу проектов с .NET 2.0 на .NET 4.0 была воспринята без единого спора. (А те проекты были на 2.0 с 2005 года).
Разница во времени выполнения была в 7.5 раз В старом коде были абсолютно неиспользуемые(т.е. тупо холостые) вызовы методов со стек-трейсом до
12 методов, которые даже в базу лезли. Но менеджерам я об этом естесственно не говорил.
Все это делалось конечно в свободное от работы время(менеджеры считали это не приносящим профита) — оно ведь мне нужно было-то.
Т.е. к чему я: заказчику или менеджерам надо предоставлять факты и цифры, глядя на которые они сами попросят вас сделать это все как можно быстрее.
AN>Запомнился эпизод с выставкой. Решили нверху показать прогу на выставке. Все было протестировано раньше и проблем никаих не было. Но в целях какой то "секретности" пришло указание убрать один параметр из показа очень быстро, так как нужный человек уезжал через час. Ну самое простое, не генерить его. Сделали — нет параметра, побежали относить копию. А во время этого решили просто прогнать базовый функционал. Ну и оказалось выдает полный отстой, так как все забыли, что от этого параметра зависят некоторые базовые подсчеты. А ведь могли и не проверить.

A_A>>Это как риски покупать или нет новый более мощный компьютер — ты ж его еще не юзал, а только слышал\читал об его возможностях.
AN>Можно было и подискутировать о правильности данного примера, но ну его.

Здравствуйте, AndrewVK, Вы писали:

AN>> Во вторых, в ветке проекта, не только исходники, но и все сопутствующее.

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

AN>>В третьих, скорость.

AVK>Скорость чего?
Апдейта конечно.
Или я апдейт сделаю за 10 секунд или буду ждать от трех минут и более — разница очевидна.

AN>> Если брать с роота обновления, то будет длиться довольно долгое время.

AVK>Да ну нафик. Долгое время это сколько? 1 минуту? 2?
Долгое время это 2 минуты в сравнении с 10 секундами.
И так ежедневно, от пяти раз на день.

Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>>Всегда ясно видно, что в проекте есть ссылка на нестандартную(не из .NET Framework) либу. Все нестандартные либы качаются с помощью батника.

Q>Зачем батники, чем MsBuild не устроил?

Всмысле, запустить msbuild для апдейта NuGet?

Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>Всмысле, запустить msbuild для апдейта NuGet?

Ну да.

Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>>Всмысле, запустить msbuild для апдейта NuGet?

Q>Ну да.

так для запуска msbuild не из студии все равно батник нужен
какой смысл запускать msbuild, который будет запускать NuGet, если мона сразу запустить NuGet?

Здравствуйте, Andrii_Avramenko, Вы писали:

A_A>так для запуска msbuild не из студии все равно батник нужен :)
A_A>какой смысл запускать msbuild, который будет запускать NuGet, если мона сразу запустить NuGet?

Чтобы выгрузка пакетов была частью процесса сборки. Т.е. на билд-сервере не нужны никакие ручные запуски каких-то батников. Чистый чекаут репозитория даёт достаточное для сборки окружение.